I need to have a RedHawk component have its ORB listen on a particular endpoint, specifically on a specified port. I am used to doing this by an endpoint parameter to ORB_init but since RedHawk calls ORB_init for me I do not know how to specify a particular giop:tcp::port endpoint. Is there a way to specify ORB_init parameters as a component property. Most programs that call ORB_init pass commandline parameters given to the executable on to ORB_init. Can I add --ORBendpoint to the entrypoint in the spd file?
Using a specific port for the ORB goes against the REDHAWK model of deployment-agnostic components. Furthermore, in the 2.1+ shared address space model, the ORB is shared between multiple components, rendering that level of control incompatible. A device or service, on the other hand, is explicitly deployed on a particular host machine, so using a specific ORB port is less fragile. As a general matter, REDHAWK attempts to abstract developers from the CORBA layer.
All of that notwithstanding, in principle it is possible to use specialized CORBA configurations. You cannot add arguments to the entry point in the SPD, but there are a couple of ways you could override the ORB port:
Edit the entry point to be a script that sets the environment variable OMNIORB_CONFIG, then exec's the real executable. Be aware that regenerating the device/service/component must be done carefully to avoid breakage (such as changing the name of the executable or overwriting your script).
Add a simple property, initialized via command the command line, called "-ORBendPoint"; I believe this would be passed along to CorbaInit. This is analogous to an execparam in SCA 2.2.2.
Modify the main() function to call ossie::corba::CorbaInit() before the call to start_component()/start_device()/start_service(). Subsequent calls to CorbaInit() will be no-ops.
Related
We have an launcher application in Windows and Unix which execs (starts application using exec system call) an application like RDP, putty, MSSQL. In order to invoke it, we pass parameters to such as username, password, IP.
Recently we found that, using wmic or ps one can find out what parameters have been passed it, thereby exposing sensitive information like passwords.
Is there any way where we can either mask those passwords or hide the parameters all together.
Note: My launcher gets parameters from a some other service, so asking for password after invoking application is not a option! Passwords have to be passed to application as parameter.
Any solutions?
This is not possible (at least not on Linux, in a reliable way) to pass program arguments securely.
A possible workaround is to pass the name of a file (or some other resource - e.g. some "reference" to some database entry) containing that password, or use some other inter-process communication facility (e.g. on Linux, fifo(7), shm_overview(7), pipe(7), unix(7), etc...) to pass these sensitive informations. You might also consider using environment variables (see environ(7) & getenv(3)).
On Linux look also into proc(5) to understand what it is able to show about processes - thru /proc/1234/ for the process of pid 1234. Maybe you want seccomp facilities.
On Unix, be aware of the setuid mechanism -tricky to understand-. Use it carefully (it is the basic block of most security or authentication machinery such as sudo and login) since a simple mistake could open a huge vulnerability.
For a software written to work both on Unix & Windows, I recommend passing the password in some file (e.g. in /tmp/secretpassword) and giving the name/tmp/secretpassword (or some D:\foo\bar on Windows) of that file thru some program argument, and make sure to use wisely the file permission mechanisms to ensure that file is not readable by those who don't need it.
I have gone through the solution provided by peter for setting system properties dynamically in multithreading with the below link
System.setProperty used by a thread impacts other thread in communication to external network elements. How to resolve it?
But the problem is, tomcat is not considering the system properties that i am setting. So how to achieve this ?
I have mutiple threads in a management station connecting to different servers through RMI APIs and download the stub accordingly.
I am referring to the same name jar file as a stub at different locations for each server.
note: jar versions may differ at each location.
Eg: MS --> serv1 --> stublocation (http://15.xx.xx.xx:port/myfolder/myapp.jar)
MS --> serv2 --> stublocation (http://15.yy.yy.yy:port/myfolder/myapp.jar)
I want to set java.rmi.server.codebase system property for each of these locations dynamically and make it threadLocal so that it will not override each other settings.
With the example provided in the above link, I hope to achieve the solution for above problem.
But to test the resolution, i am unable to set these properties in tomcat.
Tomcat is ignoring the system properties that i am setting. Tomcat is considering the JVM arguments that are set through catalina.bat or service.bat but not through the system.properties as i need it to be dynamically set.
Any help here will be great! Thanks.
The java.rmi.server.codebase property is set at the JVM which exports remote objects. Setting it in a client JVM accomplishes exactly nothing, unless that JVM exports remote objects too, i.e. callbacks. It doesn't seem likely that you will be dealing with multiple versions of your own application within the same JVM.
In short, your question doesn't make sense.
As EJP points out, (successfully) setting that property is unlikely to achieve what you want.
But there are a couple of other important misconceptions in your question.
Tomcat doesn't implement RMI. RMI is actually implemented by the Java SE itself. Therefore, it is not up to Tomcat to pay attention to those property settings.
Typical Java services that use system properties for configuration purposes do it once during the lifetime of the JVM. Typically this happens when the relevant subsystem (e.g. RMI) initializes. The problem with setting system properties programmatically ("dynamically") is ensuring that they are set before the relevant initialization code uses them.
Going back to what you are trying to achieve, it seems that it is the same as or similar to this:
Java custom classloading and RMI
Nobody was able to help that person, and he ended up solving his problem another way. (I think he is saying that he handled serialVerionId mismatches with customized readObject / writeObject methods ...)
But his Q&A offers one possible way to solve the problem. It is a bit complicated.
The RMI system allows you to provide your own classloader for RMI to use. You do this by implementing the RMIClassLoaderSpi API and then registering your providers as described in the RMIClassLoader javadoc. That's one part of the equation.
The problem is that the RMI classloader is global, but you want RMI on different threads to use different class loaders.
Solution: delegate!
You implement your custom RMI classloader to delegate to one of a number of different classloaders, depending on which versions of the remote APIs that the context requires.
Since you have proposed using thread locals, you can declare a thread local variable for use by the custom RMI classloader, and have it use that variable's value to decide which classloader to delegate to.
CAVEAT ... I have not tried this!
I'm currently using Pyro4 to create daemons that host services which are simply objects that can be called from other daemon-hosted objects or scripts. The objects take quite a long time to initialise and so I need to keep these objects alive rather then simply re-running a script that creates them each time I need to call them.
The implementation is beautifully simple, the client code executes quickly enough for my requirements and it is easy to extend functionality. However, Pyro4 is explicitly made for python programs running over a network and I am just running these daemons internally within a server. There does not seem to be python packages that handle both daemonisation and communication between daemons in the clean way Pyro4 does.
My question: is Pyro4 a right fit for my needs or is there an alternative more standard way of dealing with this use case?
Many inter-process communication protocols are using "the network" even when running on a single machine. "Network" connections on the local loopback adapter (IPV4 addresses 127.0.0.0/8 and IPV6 ::1) should be particularly fast as this usually doesn't go over a physical network interface at all.
Also, are you aware that Pyro4 also supports communicating over Unix domain sockets? Those are purely a local system resource.
All in all the phrase "Pyro4 is explicitly made for python programs running over a network" is untrue. I definitely intended Pyro4 to be used between processes even on a single computer. If there's something in particular about Pyro4 that you think is not suitable for this purpose please point it out so it can be improved!
I've recently become "reacquainted" with Windows and I'm also new to .NET & C#. I'm trying to figure out a way to run a program on a Windows 2003 machine at all times (i.e. it runs when no one is logged in and automatically starts on server boot). I think I'm overcomplicating the problem and getting myself stuck.
This program, called Job.exe, normally runs in a GUI, but I do have the option of running it from the command line with parameters.
Because of the "always on" part, the first thing that comes to mind is to create a service. Ridiculously, I'm getting stuck on how exactly to run the executable (Job.exe) from within my Service1.cs file (did I mention I'm new to c#?).
A couple other points I'm stuck on regarding creating a service are how/where to configure desktop interaction since I want Job.exe to run totally in the background. Also, since OnStart is supposed to return to the OS when finished, I'm a little confused as to where I should put the code to execute the program; do I place it in my OnStart method or create a method that I then call from OnStart?
Last question on creating a service is about the parameters. Job.exe accepts two parameters in total, one static and one dynamic (i.e. could be defined via the service properties dialog in the services management console). I'd like to be able to create multiple instances of the service specifying a different dynamic parameter for each one. Also, the dynamic parameter should be able to accept a string array.
I'm sure there are options outside of creating a service, so I will take any and all suggestions.
Since you mentioned that you may be over-complicating the problem, you may consider using the Task Scheduler to run your application.
Using the Task Scheduler will allow you to make a "regular" desktop application which is arguably a simpler approach than creating your own service. Also, the Task Scheduler has many options that fit the requirements you touched on.
The simplest approach might be to create a service, reference the application's assembly, and call it's Main() method to start the application. The application itself could use Environment.UserInteractive to detect if it is running as a service or as a desktop application.
One thing to watch out for, as you mention, is that the Start method of a service (and the other control methods) is expected to return immediately-ish (in the timespan of the "Starting Service..." dialog) so you'll need to spin up a thread to run the main method. Something like this:
Thread t = new Thread(() => { MyApplication.Application.Main("firstParam", "secondParam"); });
t.Start();
The params could come from a file and the service can be configured with the file name as a parameter (see this article for one of many examples on how to do that), or the service could be configured as you mentioned to take the parameters and pass them along to the application's main method. These are both viable approaches. Either way, only one instance of a service can be running at a time, so you'd need to register the service multiple times with different names to configure different parameters.
For some unfortunate reasons, I have to convert a proprietary and binary library from a one-user per workstation to a multi-user per workstation setup.
Current setup. A user uses a program linked against a library. This library reads a system wide configuration file (using an hard-coded path, ie /usr/local/thelib/main.conf ) which itself contains several paths to several working directories. The wdir are themselves containing a bunch of user data files.
Desired outcome. Being able to manage several users on the same workstation. Of course, a user shall not be able to read nor alter any other user's data through the library, which should be taken care of by unix rights if I manage to feed the library a different working directory for each user.
The library might be used by several users at the same time so ln-ing the configuration file in /usr/local at runtime is not an option.
I was thinking of using FUSE in order to provide a different content for the file /usr/local/thelib/main.conf, depending on an environnement variable or the current unix user. The environnement var would then be used as a switch inside the code producing the configuration file.
I'm confortable using Python, Perl or C.
The workstation is running an up-to-date GNU/Linux Debian or Ubuntu distribution with a pretty recent kernel.
So. What do you think :
would you use FUSE ?
would you produce another kind of wrapper - using chroot(2) was suggested below per janneb - ?
use something else allowed by Linux ?
I kinda know that I would be able to produce something functional but I'll get the community advice since I don't want to reinvent the wheel right now.
Thanks.
Florian
you could use LD_PRELOAD to load a small stub that intercepts open() calls, and opens ~/.main.conf (assuming this is a shared object). Then in your application startup routine, check that LD_PRELOAD is set to the correct value, and if not, restart the app with the correct environment.
A simple way would be for the app to call chroot() before calling the library init function(s). E.g. if you chroot into $HOME/theapp then each user can have a private own config file in $HOME/theapp/usr/local/thelib/main.conf as well as private working dirs somewhere under $HOME/theapp.