I am trying to run this command:
dcmqr -L SEHATYPACS:104 -cmove SEHATYPACS -I DICOM_QR_SCP#10.221.21.111:7840 -qStudyInstanceUID=1.2.124.113532.10.210.5.12.20090321.114039.3256166 -cstore 1.2.840.10008.5.1.4.1.1.3.1 -cstoredest C:\temp2\X-RAY
The command executes successfully and brings 3 matches. However, the moved images are not written to the storage directory specified in -cstoredest option. Instead, the images are written to the default storage directory defined in the JBoss JMX Management Console under "group=ONLINE_STORAGE,service=FileSystemMgt".
As you notice the command is using the -cstore option using the SOP Class UID of the image.
I need those images to override the default storage directory and use the one in the -cstoredest option.
Could you please help?
It sounds like you have a DCM4CHEE archive running on this machine with an AE of SEHATYPACS?
I expect, the AE you are requesting from (DICOM_QR_SCP) already has the AE title SEHATYPACS defined and pointing to port 11112 (or whatever you have DCM4CHEE configured to use).
I think you have a couple options: one, stop DCM4CHEE and use its port number for your listener in the command you have (dcmqr -L SEHATYPACS:11112 ...); or two, use a different AE title for your -L flag (this likely will require you to define that AE in your DICOM_QR_SCP location).
Related
I'm working on an apache module that can check the libipset API to test if an IP is in a list. This is being used as a backup firewall for proxied connections.
I've managed to get everything working up until the C script calls type = ipset_type_get(session, cmd);. After testing, I believe the main problem is that libipset requires higher permissions. I'm not getting a permission error, just a null value. However, when I run the C script directly using apache as the user, I can get it to work when I grant sudo privileges to apache for the script.
I've tried 1 and 2 in the answers here and they've both failed. Is there any other way to force root for the ipset API call?
This action might need cap_net_admin.
If using systemd to control the process, you can add it like this:
[Service]
...
CapabilityBoundingSet=CAP_NET_ADMIN
Another approach would be to set the binary executable's capabilities.
setcap cap_net_admin=ep /usr/sbin/apache2
If using apparmour, you coould instead set up a profile for apache and include the line
capability net_admin,
in the file ( /etc/apparmor.d/usr.sbin.apache2 )
( see here : https://serverfault.com/questions/932410/enabling-apparmor-for-apache2-in-ubuntu-18-04 )
I have a device running TwinCAT/BSD.
Following section 5 the manual for TwinCAT/BSD I have successfully managed to install the TF6250 package. After updating the firewall rules I have confirmed that I am able connect and issue modbus tcp requests successfully using the Default Configuration from section 4.3 of the TF6250 manual.
My project requires mapping that is different from the default (i.e to the %Q registers rather than %M). Normally (when not not using TwinCAT/BSD) I would be able to edit my mapping via the Modbus TCP Configurator, but there does not appear to be an equivalent tool contained in the package for TwinCAT/BSD.
I have tried copying the mapping files that I would have created in the configurator into the Server directory with no luck. Are you able to tell me how my mapping can be updated in the TwinCAT/BSD environment?
If relevant:
TwinCAT Build: 3.1.4024.19
TC/BSD: 12.2.9.1,2
TF6250-Modbus-TCP: 2.0.1.0_1
pkg repo: https://tcbsd.beckhoff.com/TCBSD/12/stable/packages
I spoke with Beckhoff support who told that TF6250 expects the xml file with the configuration here: /usr/local/etc/TwinCAT/Functions/TF6250-Modbus-TCP/TcModbusSrv.xml
I tested this and it appears to work so all you need to do;
Create the mapping file as per normal (e.g using the windows tool) and copy the file there.
Reboot the device to load the configuration from the file.
I am using the below command in jenkins to deploy the api proxies to apigee edge.
apigeetool deployproxy -u abc -o nonprod -e dev -n poc-jenkins1 -p xyz
But am getting the below error.
Error: Path /poc-deployment-automation conflicts with existing deployment path for revision 1 of the APIProxy poc-deploy-automation in organization nonprod, environment dev
Here is my requirement , please help me what command to use.
If API doesn’t exist in target environment, Create Api in new environment with version 1.
If API already exist in target environment, Create Api in new environment with new version (previous version + 1)
So what command should we use to fix the above error and what should we use to do the above 2 tasks.
Help Appreciated.
The apigeetool deployproxy command supports by default your requirements. It deploys the revision 1 if there is no proxy with the name, and increases the revision if it already exists.
However, based on the error you mentioned, it seems that you have a path conflict between two proxies. You are trying to deploy a proxy to a /poc-deployment-automation basepath, but there is another proxy called poc-deploy-automation which is listening on the same basepath. It is not possible, even if the proxy name is different, because the basepath is what apigee uses to redirect traffic to your proxy.
Check the xml file at the root of your proxy and change the basepath attribute.
Also, the basepath of an API Proxy can be anything, but could not be the same used at the same time by two proxies--only one can be deployed at time. The revision numbers are irrelevant in this situation.
I'm currently hosting Artifactory on Tomcat8/JDK1.8.
If I check the system info screen, I can see that files are being written in /u01/usr/share/tomcat8/.artifactory/
However, in the servlet configuration in bin/setenv.sh, I specified the Artifactory home to be somewhere else:
-DARTIFACTORY_HOME=/u01/opt/artifactory
Then, I discovered in the docs, it's supposed to be lower case:
-Dartifactory_home=/u01/opt/artifactory
I rebooted Tomcat after the changes and the path targetted is still /u01/usr/share/tomcat8/.artifactory. The folder is owned by the user running Tomcat as well.
Why isn't it using the specified home dir?
This seems a bit old but for others that struggle with it, you need to set an Environment variable ARTIFACTORY_HOME in your Tomcat startup script not a System variable via -D parameter.
Linux
set ARTIFACTORY_HOME=/pathto/your/artifactory
Windows
"set ARTIFACTORY_HOME=C:\path to your/artifactory"
Notice the quotes for Windows
System properties are set on the Java command line using the -Dpropertyname=value syntax. They can also be added at runtime using System.setProperty(String key, String value) or via the various System.getProperties().load() methods.
To get a specific system property you can use System.getProperty(String key) or System.getProperty(String key, String def).
Environment variables are set in the OS, e.g. in Linux export HOME=/Users/myusername or on Windows SET WINDIR=C:\Windows etc, and, unlike properties, may not be set at runtime.
To get a specific environment variable you can use System.getenv(String name).
I'm using the :client API to connect to an external node and use code there remotely, the thing though is that I'm using Dokku for deployment and it would be really nice if I could specify a ssh key at runtime.
Right now my code looks something like this:
def start(host) do
allow_boot to_char_list(host)
{:ok, slave} = :slave.start(to_char_list(host), :slave, inet_loader_args)
load_paths(slave)
{:ok, slave}
end
inet_loader_args == ' -rsh ssh -loader inet -hosts #{master_node_ip} -setcookie #{:erlang.get_cookie}'
I've tried something like setting the -rsh argument to be "-rsh ssh -i /path/to/id_rsh" but it seems to ignore this entirely, I'm not exactly sure how it's implemented and the Erlang docs for :client are a little hard to understand for me (I can see it uses :ssh underneath somewhere, and that can take a "user_dir" argument which can contain a key file, but I'm not sure how to set that from :client)
Any ideas?
The -rsh option is intended to point to a different executable:
%% Alternative, if the master was started as
%% 'erl -sname xxx -rsh my_rsh...', then 'my_rsh' will be used instead
%% of 'rsh' (this is useful for systems where the rsh program is named
%% 'remsh').
These days people use ssh instead of rsh. (About 10 years ago the security team on a previous job required ssh even when both machines are on the same isolated network.) Since the command line interface is compatible, just pointing to a new executable generally works once you have the keys set up properly. So it makes sense to use the -rsh option to point to ssh instead.
It also seem logical that the argument could be used to pass other parameters to the ssh command as you attempted. However, the code assumes the string passed is the name of an executable in your PATH. It uses os:find_executable to look for an executable and ssh -i /path/to/id_rsh probably doesn't exist.
However, you can take advantage of this feature to point to any executable including a shell script. For instance, you could write a ssh-wrapper that looks something like:
#!/usr/bin/env ksh
exec ssh -i /path/to/id_rsh $#
Then use -rsh /path/to/my/ssh-wrapper so that :slave.start uses your wrapper with the proper ssh options specified. I've found the wrapper technique also makes future maintenance easier as the connection logic stays in one place.
Hat tip to this comment from Martin S.