I'm trying to sort out a way to access an NFS share (ideally all privileges, but I'll settle for read only for now) from our application in Java. I've spent most of the day researching and the closest I came was the yanfs project (nee WebNFS) but it doesn't seem to have been updated since the aughties and it doesn't have any documentation either. I ran some low grade experiments with it but those were unsuccessful.
Because of the nature of our application, I can't pre-mount the volumes (there could be zero to many) and I would like to avoid calling sudo mount inside the program if at all possible. Unfortunately this approach is the only semi-viable solution I can come up with. Any suggestions would be welcome.
Also: No modern NFS java client libraries? Really? That can't possibly be right.
Have you checked out this library https://github.com/dCache/nfs4j ?
It has a server and client pure java implementation for NFSv3, NFSv4 and NFS4.1.
It is a bit low level and it does NOT provide simple usage like XFile in yaNFS.
So you have to do a bit of work to read and write to files, But at least it gets the job done, Accessing NFS exports without mounting.
You can find some file access examples at the project repo.
Since time is of the essence, we're going to cheat a bit for now. So this is the solution I worked out in case anyone comes along later.
I looked into autofs like #dsh suggested. With Autofs I set up the /etc/auto.master file to have the following line:
/mnt/fromNFS /usr/local/etc/auto.fromNFS --timeout=60
I then touched the /usr/local/etc/auto.fromNFS and changed its ownership to the user and group that is to run the app.
Now I can anagrammatically modify the auto.fromFNS file to include lines for the given nfs share. When I then go to access that directory, it nicely gets mounted with no need to sudo.
Its not ideal but it looks like it will get the job done for now.
Thanks to everyone for their suggestions.
Related
I'm aiming to create a new file extension (possibly more than one) for a program I'm creating. So, after looking around for a bit, I found a number of sources on the subject, listed below, just in case anyone wants to look at them and get the general idea of what I have been looking at.
Utilising a file association in a Java application
Create registry entry to associate file extension with application in C++
Associating file extensions with a program
http://support.microsoft.com/?scid=kb%3Ben-us%3B185453&x=6&y=11
http://www.rgagnon.com/javadetails/java-0592.html
http://www.rgagnon.com/javadetails/java-0480.html
Also, note that the Microsoft support one is actually a Visual Basic lesson, but I was just trying to see if there were any similarities in the registry changing.
Most of them generally talk about doing some registry editing so that Windows can recognize the new file and know what to do with it. Then I stumbled upon this document by Oracle, which claims that you are able to do all of the above with some (seemingly) simple Java code. I figure if it's that easy, though, somebody would have pointed it out already. Also, that document is from 2006. I've got a number of questions, which I understand can be a lot to go through, so if anyone takes time out to answer this, thanks a bunch!
What's really the best way to go about creating and associating a file type for a Java program?
If the Oracle method is used, is it done in a completely separate program? I would assume you don't want the file type being created and associated every time the program runs, and from what I've seen, that will actually return errors.
I want other people (only Windows users) to be able to easily install the program, but I'm on Windows 7 64-bit. Are there any changes I should be aware of to make the association also compatible with 32-bit systems?
Are the changes easily and completely reversible with either method (i.e. if I just wanted to create a test file extension)?
I couldn't find any extensive sources on teaching how to do this kind of stuff with no previous knowledge of it, so if anyone can't answer my questions, but does have a good source I can look at, that would be nice, too.
Java Web Start is not only a freely available installer that comes from Oracle, but it will also register an apps. interest in file types. See the File service demo. for an example.
My client wants to setup a script/file in Ubuntu in one of my client's contractors system to monitor his work/sites visited etc as long as he is in office.
His contractor will have root access in the system, so how can we make sure that the file cant be changed ? Deleting wont help him as his boss will know that because he wont get the online reports anymore after deleting.
But he can change it to the way he wants. Actually, we can write a java.java file or python or some program file but I found that even java.class files and python.pyc files can also be decompiled.
So, he can easily know the program and can easily change it.
So, any solution for this ?
Assuming you have legal issues taken care of, your only hope seem to be Encryption and Security through Obscurity.
Go for languages which are tougher to decompile, such as C/C++ (see this)
Ensure that you collect a lot of data, and store all the data encrypted so the client cannot directly access it.
Try and obsfucate to hide away your encryption keys, as well as the encryption algorithm.
Send the data from the contractor's system to the server encrypted.
Possibly also monitor whenever the contractor killed your process.
The best solution would be not to do this.
Now I don't know about your country's legislation, but in mine, any solution of this sort would be highly illegal. If the client is worried about the contractor, there would be other means of "monitoring" them.
Daily reporting
Set up a proxy blacklisting sites, possibly enforcing it over network tools
Actually meet the person and talk with them about their achievements, difficulties and such. Not inquiring, actually caring about how the project is going. If that doesn't motivate the contractor to work, nothing will.
For reasons that I guess are outside the scope of this question, I want to move a program that I have written for use with Java Web Start to stop using JWS and distribute it as an ordinary Jar file instead.
My main problem with this plan is how to figure out where to store files in a nice manner in Java, assuming I'm going to run on different platforms (though I depend on JOGL as well, so there's no great risk of running on horribly esoteric platforms, at least). My program stores various pieces of local data, mostly for caching or "caching-like" purposes -- it's extremely nice to be able to keep it, but it's not a complete disaster if the data is lost.
I currently use the JNLP PersistenceService for this purpose, so moving out of JWS I'll need to figure out some directory to store files in instead. Consider this:
File datadir = new File(System.getProperty("user.home"), ".myprogram");
I figure this works well on Unix and Unix-like platforms, but it's clearly ugly, at least, on some platforms like Windows where I guess I should use the AppData directory or whatever it's called again.
My current line of thought is to use this datadir as a default fall-back everywhere except on known platforms where I replace it with something better, like Windows. The questions I have about this are these:
Is this a reasonable default to begin with? I'm kind-of-fine with this failing on some unknown platforms; I'll just silently disable caching and some extended features if this is the case, but could it fail in some manner that leaves actively bad results?
Is there any good way to figure out I'm on Windows? The best thing I can figure out right now is to match some patterns against os.name, which I guess should work well enough, but is there a better way? I don't intrinsically mind testing with reflection to see if some sun.* packages exist that could help out or something (with the risk of falling back to defaults), if that is good. (Question applies in general to all platforms; are there any somewhat robust idioms for figuring this out in general?)
Is there a good way to figure out the directory to use on Windows? Using static paths seems ugly since I know they can be overridden with registry settings, or be localized and whatnot.
Are there any other platforms I should think of from the outset? My datadir should work fine on OSX, right?
Is there any better alternative altogether?
Consider using the java.util.prefs.Preferences API for this purpose.
If it's just cached data that is replaceable I would just recommend using the temp directory.
See:
new File(File.createTempFile().getParent(), 'my-file-name');
You can set it to be destroyed on your app shut down or just leave it there.
If you want more of a semi-permanent but out of the way storage you may need to care what OS you're on and act accordingly like the answers to this question
I'm aiming to create a new file extension (possibly more than one) for a program I'm creating. So, after looking around for a bit, I found a number of sources on the subject, listed below, just in case anyone wants to look at them and get the general idea of what I have been looking at.
Utilising a file association in a Java application
Create registry entry to associate file extension with application in C++
Associating file extensions with a program
http://support.microsoft.com/?scid=kb%3Ben-us%3B185453&x=6&y=11
http://www.rgagnon.com/javadetails/java-0592.html
http://www.rgagnon.com/javadetails/java-0480.html
Also, note that the Microsoft support one is actually a Visual Basic lesson, but I was just trying to see if there were any similarities in the registry changing.
Most of them generally talk about doing some registry editing so that Windows can recognize the new file and know what to do with it. Then I stumbled upon this document by Oracle, which claims that you are able to do all of the above with some (seemingly) simple Java code. I figure if it's that easy, though, somebody would have pointed it out already. Also, that document is from 2006. I've got a number of questions, which I understand can be a lot to go through, so if anyone takes time out to answer this, thanks a bunch!
What's really the best way to go about creating and associating a file type for a Java program?
If the Oracle method is used, is it done in a completely separate program? I would assume you don't want the file type being created and associated every time the program runs, and from what I've seen, that will actually return errors.
I want other people (only Windows users) to be able to easily install the program, but I'm on Windows 7 64-bit. Are there any changes I should be aware of to make the association also compatible with 32-bit systems?
Are the changes easily and completely reversible with either method (i.e. if I just wanted to create a test file extension)?
I couldn't find any extensive sources on teaching how to do this kind of stuff with no previous knowledge of it, so if anyone can't answer my questions, but does have a good source I can look at, that would be nice, too.
Java Web Start is not only a freely available installer that comes from Oracle, but it will also register an apps. interest in file types. See the File service demo. for an example.
All right, I've hit a bug that has simply confused the bejeebus out of me. I'm looking for ideas about what it could be that I can investigate, because right now, I got nothing. It goes something like this:
I have a standalone Java application that occasionally needs to twiddle the Line-In volume of the computer it's running on (a WinXP machine). It does this by calling a pair of external executables (written in VB6*) that can get and set various component volumes. (They can handle Line-In, Mic, Wave, CD, and the master volume control.)
There are several hundred units in the field, running on hardware (Dell machines) that my company provided and controls. At least several dozen clients are using this feature, and it works perfectly -- except for one instance.
For this one troublemaking machine, it simply doesn't work. I watch the volume sliders when the app is running, and when the volume is supposed to drop, they stay put. When I check the app's log file, it throws no errors, and appears to be executing the code that drops the volume. When I run the executables from the command line, they work perfectly.
I can't vouch for this machine being 100% identical to all the ones that are behaving properly, but we've been buying the same line of Dells for quite some time now; at a bare minimum, it's very, very similar.
So, turning my confusion into a bullet list:
If I'm doing something stupid in the Java code (i.e., not clearing my STDOUT/STDERR buffers), why is it only an issue on this machine?
If there's something broken in the VB6 executables, why do they work on every other machine and on this machine from the command line?
If there's some sort of hardware oddity on this machine, what sort of oddity could cause the volume control executables to fail only when called from within a Java application?
I am very confused. I do not like being confused. Anybody have any suggestions that may lead to my enlightenment?**
-* -- I know, I know, VB6, 1998 called and they want their obsolescent proprietary bug generator back, etc. Wasn't my decision. But the code works. Usually.
-** -- Insert Buddhism joke here.
Update Edit: Customer service may have stumbled onto something; it may be something to do with client configuration settings in the database. New evidence suggests that either something's misconfigured for that client or my software is doing something stupid in response to a specific configuration. And the problem may be more widespread than we thought, due to this particular feature not being as commonly used as I thought.
Responding to the comments:
Debugger: Theoretically possible, but looks like a massive headache given our setup.
High Verbosity Logging, Java: Good idea this, particularly given than the problem may be more widespread than I originally believed. Time to start revisiting some assumptions. And possibly clubbing them. Like baby seals.
High Verbosity Logging, VB6: A possibility; will need to be rolled-into the high-verbosity Java logging to trap the output, since my VB6-fu is so pitiably weak I don't know how to output text to a file. But, yeah, knowing whether or not the script is even getting called would be valuable.
Window Event Viewer: Not familiar with this tool. May have to correct that.
PATH problem: Doesn't feel likely; the Java code constructs a relative path to the executable that doesn't look like it's relying on any environment variables.
My thanks for the suggestions people have provided; at the very least, you've gotten my brain moving in directions that feel promising.
Solution Edit: And the winner is ... That's Not A Bug, That's A Feature! A feature gone horribly, horribly wrong. A feature that will now be neutered so as to stop bothering us.
A batch of invalid assumptions kept me from seeing it sooner, not the least of which was "I don't need to tool the code with more debug statements -- the statements already in there are telling me all I need to know!" DaDaDom, if you'd like to turn your comment into an answer, there's a shiny checkmark in it for you.
Thanks to everybody who chimed in with a suggestion. Now if you'll excuse me, my head is late for a meeting with my desk.
Here goes an answer:
Can you create a version of the software with verbose logging or could you even debug the code? At least then you can tell if it's in the java or the VB part.
Hmmmm. I've been told that executing programs from Java is either easy or hard. The easy part is starting them up. The hard part is dealing with the I/O streams (see my earlier question on using Runtime.exec()). Maybe the VB program is doing or expecting something weird on these particular machines that the Java code isn't working with properly.
edit: I also found a link to Jakarta Commons Exec:
Rationale
Executing external processes from Java is a well-known problem area. It is inheriently platform dependent and requires the developer to know and test for platform specific behaviors, for example using cmd.exe on Windows or limited buffer sizes causing deadlocks. The JRE support for this is very limited, albeit better with the new Java SE 1.5 ProcessBuilder class.
Reliably executing external processes can also require knowledge of the environment variables before or after the command is executed. In J2SE 1.1-1.4 there is not support for this, since the method, System.getenv(), for retriving environment variables is deprecated.
There are currently several different libraries that for their own purposes have implemented frameworks around Runtime.exec() to handle the various issues outlined above. The proposed project should aim at coordinating and learning from these initatives to create and maintain a simple, reusable and well-tested package. Since some of the more problematic platforms are not readily available, it is my hope that the broad Apache community can be a great help.
Have you considered the possibility that the authenticated user may not have permission to edit volume settings on the workstation? Does the program run correctly if you run as an 'Administrator'?