I think this might be an IIS7 permissions thing, but I'm tagging it with OpenWrap because I might be wrong. When I try to publish a wrap to an HTTP repository I get the following error:
PS C:\OpenWrapExamples\Ninject> o publish-wrap -Name Ninject -remote MyHttpRepo
# OpenWrap Shell 2.0.0.10
# Copyright © naughtyProd Limited 2009-2011
# Using C:\OpenWrapExamples\Ninject\wraps\_cache\openwrap-1.0.1.81349963\bin-net35\OpenWrap.dll (1.0.0.0)
Publishing package 'Ninject-2.2.0.85378492.wrap' to 'MyHttpRepo'
The repository OpenWrap.Repositories.Http.HttpRepositoryNavigator is read-only.
I've tried setting the permissions on the folder, but that doesn't work either.
If you just exposed an indexed-folder (one you added with file:///path/) as an IIS site, it will be read-only (as there's little we can do with that).
If you use OpenWrap 1.0, , you can simply add two remotes, one for the UNC path (so you can publish) and the other one for the http one (so you can read the content back).
If you use the upcoming OpenWrap 2.0.1, you can simply add both in one go
o add-remote http://server/ -publish file://server/path/to/share
If you want a repository writeable over HTTP, you can implement that feature yourself rather easily: have your index file at /index.wraplist, add an endpoint that support a POST with some content (that's the package), say at /upload, and add the following to your index.wraplist:
OpenWrap will then happily upload to an http endpoint.
Related
We have a similar problem to that of the asker of this question -- after upgrading from log4j-2.17.1 to 2.17.2, the application, though otherwise working, is not logging anything.
Having read the release notes, I see the following part:
By default, the only remote protocol allowed for loading configuration files is HTTPS.
Users can specify a system property to allow others or prevent remote loading entirely.
Indeed, in our case the log4j2.xml is downloaded via regular (non-encrypted) HTTP, and that likely explains our problem (as well as that of the other guy). However, try as I might, I cannot find, how to (re)enable the ability to use HTTP -- which system property is it, that now controls the capability?
Thanks!
The system property you are looking for is called log4j2.Configuration.allowedProtocols (cf. documentation) and should contained a comma separated list of URL schemes (e.g. "http,https").
You can set it using any available property source (e.g. a log4j.component.properties file or a Java system property).
I'm setting up a REST server with web services on Drupal 7. I'm getting the error report:
The Spyc library could not be found
I downloaded the Spyc.php library (from https://github.com/mustangostang/spyc) and uploaded it to:
/sites/all/modules/services/servers/rest_server/lib/
And also tried putting it in /servers/rest_server/lib/Spyc/, but I still get the error.
The answer above appears to be out of date.
Downloading spyc from the link above and placing in sites/all/libraries/spyc takes care of the problem. No changes to capitalization are necessary.
The Services module documentation is not accurate!
...Once downloaded you need to add spyc.php to the rest_server/lib folder which exists under
the location you have installed services in.
You simply need to create a spyc folder containing spyc.php and place it in the sites/all/libraries, as should be expected with any external libraries.
I'm moving from IBM RAD 8 / WAS 7.0 to IBM RAD 9 / WAS 8.5. Liberty Profile. There's a plenty of configuration things such as URLs and namespace bindings.
I've found an information that WSADMIN is not working for Liberty Profile. I haven't found, however, the information, how to access similar functionality as in wsadmin/jython, for example for creating URLs, namespace bindings, etc.?
How to script such things under WebSphere Liberty Profile?
I'll try to address a few things that are implied by your use of wsadmin. I may be overshooting, but I hope this helps:
WSADMIN applies only to the full WebSphere Application Server. jython scripting for the Liberty profile is possible, though you're basically performing JMX operations on a server. Here is something to get started with: https://www.ibmdw.net/wasdev/docs/creating-remote-jmx-connections-with-jython/
There is no way to reconfigure a Liberty profile server via a JMX operation, however. All server configuration (or reconfiguration) is done by editing the server configuration file (either manually with an editor of your choice, via the eclipse tools, or with a script that modifies your XML).
The Liberty profile does not support CORBA or CORBA namespaces (corbaloc or corbaname), or remote EJBs. Liberty profile servers also are not part of the cell/node topology of full profile servers. Instead, Liberty profile servers form collectives, as described here:
http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.core.doc/ae/cwlp_collective_arch.html
You can add strings to JNDI using the jndiEntry element in your server configuration as described here: http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.core.doc/ae/twlp_dep_jndi.html
Information about configuring datasources (I am guessing at what you might need URLs and namespace bindings for) is here (see also the subtopics): http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/topic/com.ibm.websphere.wlp.core.doc/ae/twlp_dep_configuring_ds.html.
The easiest way is to edit the XML directly or using a script in the language of your choice. The idea is that the config is simple enough wsadmin is no longer needed - it's intended to be human readable and human maintainable. You can import XML snippets if you have repeated config elements you want to share similar elements across multiple servers, or create the same config elements multiple times.
Can somebody explain (better than the technet/msdn docs) what the auto provider exactly does, how it works, and when to use it.
This is in regard to Web Deploy. I've seen a lot of documentation specifying -dest:auto and it's not really making sense to me.
The auto provider specifies that the provider on a destination will be
the same as the source provider.
Example
msdeploy.exe -verb:sync -source:appHostConfig="MySite"
-dest:auto,computername=Server1
The auto provider enables you to avoid entering the full path for the
-dest argument when the destination argument is the same as the
-source argument. It also removes the need to copy the manifest file
separately from an archive or package.
The auto provider takes the source that you specify and uses a
corresponding location on the destination computer. For example, if
you specify appHostConfig=Site1 as the source, the destination on the
target computer will be Site1. This is useful when you want to
synchronize a Web site "as is" to a remote machine.
technet docs for auto provider
Example that doesn't make sense:
msdeploy.exe -verb:sync -source:package=myapp.zip -dest:auto
Why would you ever set the destination exactly to the source? What is the point? Aren't you simply overwiting the source with iteslf?
The generated cmd file generated from publishing a package in VS2010 generates something like this:
"C:\Program Files\IIS\Microsoft Web Deploy V2\\msdeploy.exe" -source:package='MySourcePath' -dest:auto"
Doesn't auto mean the source will just overwrite itself? But it doesn't, it actually updates the IIS web site (based on the settings in the manifest)
I've tried using package as the destination and in this case it did update the source package and not the IIS site.
The catalyst for this question is that I'm implementing CI and I 've always used msbuild/xcopy in the past. I want to utilize msdeploy now. I want to understand it rather than simply calling the myproject.cmd that's generated from visual studio.
For example, this SO link specifies using the auto provider for the dest argument.
Thanks
I think you've actually figured out the answer for yourself.
If the source is a package and the destination is auto, that simply means that the components specified inside the package will be "unzipped" and placed on the destination server. In the -source:package -dest:auto syntax, "auto" does not mean that the package itself is the destination.
And, as you observe, if you specify a package as the destination, whatever you specify for the source will indeed be packaged up as a zip file that you can later use as a source to deploy elsewhere.
I'm trying to set up the automated (nightly) installation of my web site setup project. I can specify some install-time values on the command line; in particular, adding a TARGETSITE value defines the web site to which my new deployment will go.
How do I find the metabase key to my web site (eg. "/LM/W3SVC/213548468") in an IIS7 installation? (I do have IIS6 compatibility all set up, but I can't find anything about my site in the metabase.xml file.)
Also, since the web deployment setup projects are obviously outdated mechanisms (I guess they were too easy to use?), does anyone have a better idea for my nightly automated deployments?
In IIS 7 and above we do not use the metabase anymore and instead moved to a ".config" model where we store all the settings inside "%windir%\system32\inetsrv\config\applicationHost.config", that is where you will find all the information and settings you apply. If you enable IIS 6 compatibility we will run all the commands by translating them directly into the new ApplicationHost.config.
It would be useful to know more about how you are doing it today, If you use Managed code probably the best solution is using Microsoft.Web.Administration (Link) which includes a class called ServerManager to allow you to set everything you need.
If you use scripts (vbscript/jscript) you can continue using your scripts or instead use AHADMIN which is our new underlying COM configuration api.
if you use powershell we also have a PowerShell provider (http://www.iis.net/download/PowerShell) provide which should be the best in that case.
Also, if you actually want to package contents and configuration and other stuff like Registry settings, COM objects, GAC dlls, etc, you should use Web Deploy (http://www.iis.net/download/WebDeploy)
I know nothing about metabase, but from your posts I was able to cobble together the following:
import-module WebAdministration
$site = get-website | Where-object {$_.Name -eq "SiteName"}
$id=$site.ID
setup.msi /passive TARGETAPPPOOL=`"ASP.NET v4.0`" TARGETSITE="/LM/W3SVC/"$id
The backtick marks are the escape characters for powershell.