I'm running into an issue where I do not have write access to the /var directory on a UNIX environment, and InstallAnywhere doesn't provide me the option of writing the .com.zerog.registry.xml to any other location for a product installation. Is there a parameter out there that allows for this file to be written to a different directory?
According to the IA docs:
If logged in as root, the global registry is located in \var.
If logged in as a user, it is located in the user’s home directory.
So, if you're running as root and can't write to /var, it sounds like a permissions problem with the /var directory, independent of IA. Check the permissions on /var.
If you're running as a non-root user, then the registry shouldn't be going to /var, but to $HOME/.com.zerog.registry.xml (FWIW, I just checked one of our test Linux boxes and found .com.zerog.registry.xml under both /var and under test-user $HOME directories. The docs appear to be correct).
I've also seen some very strange behavior if IA is low on space in $TMP. Make sure you have plenty of space there.
Also, have you considered running the installer with sudo, or the graphical equivalents kdesudo (KDE) and gksu (Gnome)? Those might get you where you want to go.
Related
I have created quite a few deb files, i have no problems doing that and they all run beautifully. However, if i want to replace a file in users home directory I am unsure on how to do that.
I have tried making a postinst to rsync the files from a predefined location to home directory, but since the postinst file is being run as root ( due to the debian installer running as root ) it is being sent to the root home directory and not the user's home directory....
Here's an example of the deb file contents :
Debian Directory ---> Control File ----> Postint File
usr/share/desktop (directory with files inside)
The postinst file has the sync command to send those files to users home:
#!/bin/sh
rsync -av /usr/share/desktop/ ~/.config/desktop/
The problem is it is sending the files to Root/home... not the default users home :(
I don't have the username of the user since this will be used on many computers with different users, therefore I can't use sudo -u username.
So what do I do? how do i replace files in users home directory from deb install? Any help is much appreciated.
In a Bash script, ~ refers to the current user's home directory. The package installation scripts are always run as root, so that's what "current user" means in this context.
(You could argue that the package installation is probably initiated by a user running su or sudo, but in the general case, you cannot assume this to be the case.)
Modifying user files from a system package appears extremely suspicious in any event. If the need is genuine, this should probably not be approached as a system package installation question in the first place. What are you actually trying to accomplish?
Not only are you violating the basic principle that package management should not meddle with user files; a consequence of this arrangement is that the operation can only be performed once: If the user has installed the package, attempting to install it again does nothing (at least until you uninstall).
A more manageable and predictable approach would seem to be making the package provide this functionality, but leave it to the user to invoke the actual sync (overwriting) script as needed. Perhaps you want to hook it into the desktop startup scripts somehow.
Having said that, sudo exposes the invoking user's identity in $SUDO_USER so you could look for that, and simply fail if it is not set.
As an aside, package scripts should work with dash so you need to avoid bashisms - prefer $HOME over ~, for example.
I managed to find a workaround, although it is not exactly what I was looking for, but here is my solution, at least for now.
#!/bin/sh
#This will move the desktop settings to required folder.
szAnswer=$(zenity --entry --text "Enter your login username\nThis must be entered correctly\n" --entry-text "Enter name of profile to use:")
xfce4-terminal -e "sudo rsync -av /usr/share/Desktop/ /home/$szAnswer/.config/xfce4/"
exit 0
In other words, the user gets asked to enter his username, and the files get copied to that user's home directory. The advantage is that if he does have multiple users, it will use the correct user. The disadvantage is if he enters username wrong, even a spelling mistake, the install will fail.
But it does work, I have tested. If anyone has a better solution I eagerly await your suggestions.
I'd like to read/write files using nodejs that live in a protected directory (/etc/apache2/sites-available). I understand that I can run the script with sudo but the idea of that makes me worried. Is there some way I can have node try to elevate for certain functions/calls without having the whole script run with root access?
If you do not provide elevated rights to your script, the script will be unable to mysteriously obtain those rights out of the thin air.
Granted you still need to modify the files, then consider giving write permissinos to your app.
If you are running app as user joe, and owner of sites-available files is root, then do: chown -R joe:joe sites-available.
But if some other user already uses those files, then you might get into permissions conflict. In this case, you can workaround using shared group, or SSH as that user.
Shortly, there are several ways of achieving your goal. But it is completely unrelated to Node.js technology, and all about linux, chown and chmod.
I need to grant jenkins user permission to access some specific directories like usr/lib or usr/local/include so that he can copy some files into those directories during the execution of some Jenkins jobs. How can I do that?
The idea that something accessed from the web can overwrite system files is very scary (and insecure), but I think you would need to grant the user under which Jenkins is running the privileges need to write there.
Again, there are good reasons why ordinary user's aren't granted permissions to write to those directories. You might want to consider running the job in a chroot jail. That way, if something goes wrong, you won't destroy your system.
For specific task i would say use sudo
You mentioned usr/lib or usr/local/include directories, and if your goal is to install some tools and packages during job execution, you could install it locally into your job workspace (for example, into .local directory) and after that make your jobs work with those directories by setting environment variables like LD_LIBRARY_PATH, CFLAGS, etc.
I'm looking for any advice/intuition/clues/answers on a permission issue that has been plaguing me ever since I switched over to a new Macbook pro. Here's the dilemma. Certain programs copy libraries under /usr/local/lib during install and upon running these programs I get a crash which I believe is related to permission restrictions to files in this folder. I've had errors (can't access files from this path) trying to install plugins for audacity and then tried doing an "ls" under this folder. I immediately get permission denied unless I prefix the cmd with sudo. I've tried owning the /usr/local/lib/audacity folder with my user account and even still I get permissions errors on these files. It's important to note that the problem is not exclusive to Audacity. I've seen the same problem with Polycom video conference software and I've also been unable to run Parallels on this machine. (I haven't traced Parallels to the same issue but I'm betting its related.) I vaguely recall some weird Linux cmd magic I used to use back in the day that would not only grant permission to a user but tweak some low level bits allowing/disabling certain things like execution and I seem to recall the permission thing ran deeper than execution but its been years. I can't recall the detils and I'm wondering if there's something similar on OS X that I'm possibly overlooking. Is there something special about that location and the files there in? Could I have somehow altered my file system in a way tht the files appear different? For what its worth, I seem to be able to use at least one of the programs if I log in as root. I haven't tried with the other programs as I've just discovered the ability. Please help.
It sounds like the folder isn't world executable. Try:
sudo chmod 755 /usr/local/lib
and then you should be able to use ls or anything else in the folder (still won't allow you to write but your user account shouldn't be able to do that anyway)
Found the answer from a coworker buddy. The folder needed to be marked executable.
sudo chmod 755 /usr/local/lib
fixes everything!
I'm writing an install script in bash for an application on Linux.
This script copies some files into /usr/bin and /usr/share, so it needs to be executed by a root user, furthermore it makes an hidden directory in the $HOME dir for configuration files.
Here is the problem: if a normal user wants to install the program, he needs to be root. But if he is root, the $HOME directory will be /root/ instead of /home/username.
...and, further, if UserA installs the software, but UserB runs it, UserB won't have the hidden directory under /home/UserB. Also, the hidden directory under /home/UserA will be owned by root, not userA.
So, you need to have the application create the hidden directory, not the installer.
Another possible option is not to install in the system directories; one possible alternative location is /usr/local. However, even that can require root privileges. Think about whether it can be installed in other places, and how it could locate its materials.
However, requiring root privileges to install is not the end of the world - a nuisance for some, but not completely out of order. But requiring everyone who uses to have root privileges is way out of order - and if everyone who uses it needs to run the installer, that is bad.
Final point (for now): if you use sudo, it does not change the value of $HOME, even as you acquire root privileges. However, requiring everyone who uses your application to have sudo privileges is not a good thing either.
Must you use $HOME? Maybe you could prompt for the username and install to ~$username instead?