In DFS Management, when we try to manage one of the namespaces, the error is:
\\mydomain.com\mynamespace: The namespace cannot be queried. The specified domain either does not exist or could not be contacted.
When I use dfsdiag /testdfsintegrity /dfsroot:\\mydomain.com\mynamespace, the output is:
Error: The RPC server is unavailable.
Error: The specified domain either does not exist or could not be contacted.
Warning: Unable to access the DFS metadata for the following namespace: \\myserver\mynamespace
Finished TestDfsIntegrity.
We retired myserver within the last few months. I speculate that it was the only namespace server for this namespace. I can still browse this namespace in file explorer; I just can't manage it in DFS Management.
Is there a way to set up another server to be the namespace server for this namespace?
My solution was to delete the namespace and recreate it.
Before deleting it, I needed to record what folders were in the namespace. Fortunately, I could still browse the namespace in file explorer. I made notes about what everything was pointing to.
I could not use the DFS Management tool to manage the namespace at all. To delete it, I did the following:
Run adsiedit.msc.
Connect to the default naming context.
Navigate to DC=mydomain, DC=com > CN=System > CN=Dfs-Configuration.
There is listed all of the namespaces. Delete the problem one.
Running the commands "repadmin /syncall" and "dfsrdiag pollad"
supposedly cause everything to sync up.
Then I could use DFS Management to recreate the namespace.
Related
I am trying to use HSQLDB in server mode, but cannot get the ACL to work.
I started a server (creating a fresh database) with this command line:
java -cp $CLASSPATH:/usr/share/java/hsqldb.jar org.hsqldb.server.Server --database.0 file:~/workspaces/foo/db/fooserver --dbname.0 fooserver
I can connect to it with HSQL Database Manager and issue a SHUTDOWN.
Next, I created an ACL file in ~/workspaces/foo/db/fooserver.acl with the following content:
deny 127.0.0.1
I sucessfully tested it with java -cp $CLASSPATH:/usr/share/java/hsqldb.jar org.hsqldb.server.ServerAcl ~/workspaces/foo/db/fooserver.acl, and it tells me 127.0.0.1 is denied access.
Now I created ~/workspaces/foo/db/server.properties (as there was no server.properties file yet) with the following content:
server.acl=traffserver.acl
However, when I now launch the server, I can still connect to the database.
HSQLDB version is 2.4.1, as shipped with Ubuntu 18.04.
Other things I have tried:
This mailing list post suggests using server.acl_filepath instead of server.acl. Behavior is still the same.
I have tried adding either property to fooserver.properties. Still no effect, and the property gets deleted when I stop the server.
What am I missing?
First of all, if you use a server.properties file which is not located in the directory where you execute the java command, you should include the path to that properties file.
In the same scenario, in the server.properties file, you need to use the same path as you successfully tested. So it should be:
server.acl=~/workspaces/foo/db/fooserver.acl
It would be easier to specify the properties and acl files if you issue the java command from the directory that contains both files. In that case you can use a short filename instead of the full path.
See the Guide http://hsqldb.org/doc/2.0/guide/listeners-chapt.html
I am trying to configure wso2 by modifing its configuration file named "carbon.xml", but no matter what change I do to "carbon.xml", even adding a single "white space" or modifying a comment it's enough for the wso2 server to reset carbon.xml file to it´s original "out of the box" state.
I tryied to protect the file carbon.xml by dropping write permissions, but in this case wso2 server refuses to start, it aborts execution and displays an error complaining that it was not able to "write new configuration" !!!
Does any one know how to solve this?
I found the answer, In wso2 version 5.9 there is a new centralized configuration file, named "deployment.toml". Configurations must be done in this file and then wso2 propagates changes to the respective configurations files, like carbon.xml or catalina-server.xml, for example.
If you delete "deployment.toml" wso2 will fallback to previos behavior.
With the new 4.5.0 carbon-kernel release, all WSO2 products such as APIM 3.0.0, IS 5.9.0 introduced a new config model. According to the new config model, there is a centralized configuration file (deployment.toml) where users add the configurations, then those configurations will be added to the respective .xml files.
This new config model was introduced in order to simplify the configuration (previously there were a lot of configuration files) and to increase the user experience. Please follow this documentation to refer further information on this new config model
Related documents:
https://wso2.com/blogs/thesource/2019/10/simplifying-configuration-with-WSO2-identity-server
https://is.docs.wso2.com/en/next/references/new-configuration-model/
If you have a deployment.toml file, the changes directly made into the xml files will be overiden during the server startup. Deleting the deployment.toml file will use the old config model. But it is not a recommended approach.
How can I get ejabberd to run an external auth script on windows?
So far- I've modified the file
C:\Program
Files\ejabberd-15.06\lib\ejabberd-15.06\priv\cfg\ejabberd.yml
to comment out the existing auth_method directive and instead added this:
auth_method: external
extauth_program: "D:\\DROPBOX\\Dropbox (Personal)\\EJABBERD\\auth\\ejabberd-auth.exe"
However, when I try to connect to the server- I see nothing in the logs indicating an attempt to run the script. I've even tried changing it to a non-existant file to see if that will log an error of some sort, but nothing.
All I get are "Accepted connection" type of logs.
In case it matters- upon start I do get several "unknown option" errors, including "ejabberd_config:validate_opts:752 unknown option 'auth_method' will be likely ignored" - however it seems this is a known, cosmetic-only error (see: https://github.com/processone/ejabberd/issues/630)
I do not use Windows, but, you should try playing with Erlang open_port command:
open_port({spawn, "YOURCOMMAND"}, [{packet, 2}]).
Note that open_port Erlang documentation says:
For external programs, the PATH is searched (or an equivalent method is used to find programs, depending on operating system). This is done by invoking the shell on certain platforms. The first space separated token of the command will be considered as the name of the executable (or driver). This (among other things) makes this option unsuitable for running programs having spaces in file or directory names.
I see your path has spaces. That alone should indeed make it impossible to call your command.
That said, external_auth command has never been tested on Windows. You may need to patch ejabberd command to make that authentication through external process work. I would be surprised if it works as is.
I've configured my SSIS configuration to load from an XML file. When I run the package with dtexec, I specify a different configuration file for each country I'm processing. In Visual Studio I specified this as France.dtsConfig (I have to choose one and this was the first one).
When I run the package with dtexec /FILE Import.dtsx /Reporting V /ConfigFile "C:\Italy.dtsConfig" I still see the output telling me that "The package is attempting to configure from the XML file France.dtsConfig".
I thought I could override the configuration by providing a different dtsConfig file for each country. Is this possible? What am I doing wrong?
I am using SQL Server 2008 R2 and I was getting the same issue with the Configuration override apparently being ignored. I found the trick I needed was to remove the XML config setting from the package (Package Configurations), and then when running the package the XML configuration file you specify is applied. There is however no message emitted about using the file (and since you removed the XML configuration definition from the package, that message is also not emitted).
MSDN has an explanation (go to section "Understanding How SSIS Package Configurations Are Applied at Run Time") that at first didn't make sense to me, but after finding that not having an XML configuration file defined gives the desired result, I can see what it is trying to say.
In my case I was using the XML file to set the instance name of the server on which the [SSIS Configurations] table was found. At design time this was DEVServer in the connection manager object, and I want to override the value to TESTSvr. Following the rules:
"The utility applies the configurations that were specified in the package at design time and in the order that is specified in the package." So the value DEVServer is loaded from the package.
"The utility then applies any options that you specified on the command line." The value in my XML file (TESTSvr) is now loaded. I can supply any filename I like here, and it will be loaded (be it France or Italy).
"The utility then reloads the configurations that were specified in the package at design time and in the order specified in the package. ... The utility uses any command-line options that were specified to reload the configurations." Note the second part of the rule, about using the command line values. Since we currently have set the server to TESTSvr, this value is now used to load the other configuration values from the [SSIS Configurations] table that you want.
I don't have a reference to an article that documents this behaviour, but I have confirmed it. If the file specified as the configuration file in the package configurations is available at run time, it will be used in preference to the one specified on the command line.
In my experience and my opinion, this is contrary to normal behaviour where specifying something in a command should override the built-in default.
To use the configuration file specified in the dtexec command, rename or delete the file that is specified in the Configuration String of the XML configuration file in the Package Configurations Organiser.
Found a way!
In the designer simply uncheck the "Enable package configurations" option under SSIS -> Package Configurations, and save.
dtexec will still honour the supplied configuration file on the /conf switch, but it will no longer attempt to use the design time configuration file even if is accessible.
I still agree that this is strange behaviour, and that the /conf should override design time settings no matter what.
This should work
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Specify the complete config file location within double quotes
Edit :
When you have deployed your package in MSDB then the command to execute the package is
DTEXEC /SQL "\Package.dtsx" /SERVER "Server Name"
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Else if you have deployed in File System then
DTEXEC /f "Physical Package Location"
/CONFIGFILE "C:\Italy.dtsConfig" /REPORTING V
Check whether you are pointing to the correct package
MSDN
You can use the /ConfigFile option to load additional configurations
at run time that you did not specify at design time. However, you cannot
use the /ConfigFile option to replace configured values that you also
specified at design time
I have an SSIS 2008 Package that imports some data and then writes out a text file to a local folder on the computer. Everything built, deployed and installed fine, and in my XML configuration file I have a property to set the location of the local folder. I also use an operating system Environment Variable to redirect the location of the XML Configuration file at run time. On my development machine I set the drop-off folder location to C:\Temp, but on the target computer I want this drop-off folder set to E:\SSIS\FileDropOff and I make that configuration setting change at install time. The setup for everything looks fine to me, configuration file looks ok, there were no warnings or errors in the validation check at install time, the Environment Variable is pointing to the right place, and the SSIS Package is installed in the SQL Server MSDB database.
The problem is when the SSIS Package runs on the target computer, it keeps writing the text file to C:\Temp. No matter what I do I can't seem to get it to write to the E:\SSIS\FileDropOff folder. It's like the SSIS Package is stuck on C:\Temp and is ignoring the the XML configuration file setting on the target machine. In the SQL Agent running the SSIS Package I even tried checking the box on the Job Step Properties screen, Data Sources tab and set the Connection String to E:\SSIS\FileDropOff and it still doesn't work.
Is there any place I could be missing where the SSIS Package is looking at C:\Temp? Could there be a cached value someplace that I am not aware of that forcing the package to stick on C:\Temp?
Thanks.
1.) Try restarting your SQL Agent Service. If I remember correctly, it caches environment variables.
2.) Try setting up a package variable and using that to set the connection string instead of the xml file directly.
I believe it's a common mistake when moving between environments (i.e., dev - test - prod) to forget to right click on your package in the new environment and select the latest XML config file. So what's happening is your package is still looking at the old XML config file. You need to right click, and choose to browse and open the one intended for the specific environment.
Make sense?
If you didn't do this you may have unintentionally overwritten your config file.