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.
Related
I wrote Postinst script for changing owner and file permission:
chown -R $(whoami) ~/Desktop/my_file.desktop
chmod 777 ~/Desktop/my_file.desktop
but after installation it does nothing.
I'm really not getting what part of script is wrong. Please tell how to get dynamically username in Postinst script?
Package installation runs as root, unconditionally. There is no concept of an invoking user; indeed, the package installation may happen e.g. before any user accounts exist on the box.
It's extremely unclear what you actually hope to achieve, but it looks like perhaps your package should simply install a script which then performs the task when the user runs it. This will also conveniently create a file which is already owned by the current user, without any chown trickery.
Even if a user exists, there is no guarantee that they have a Desktop directory in their home directory, or that they are currently, or ever, logged in using a GUI.
Finally, whatever you are attempting to do, chmod 777 is wrong and dangerous. You should absolutely not assign write access for everyone, to anything, ever.
(Okay, so there are two or three obscure scenarios related to system administration where this is actually required and useful; otherwise it should probably be technically impossible in the first place.)
I just found Matlab (2016a) put a 2.5 Gb installation files that it fetched during the installation in the root home directory (Linux mint 18), under /root/Downloads/MathWorks. I guess it is probably because I use sudo for installation.
My question is:
Is it normal that program store information when user executes it with sudo?
Can I delete the file under /root/Downloads? (My limited Linux knowledge told me do not touch anything in the /root folder)
When you execute anything with su...do, you basically execute it 'as' root.
Mathworks uses the Download-Folder (which is in your case /root/Downloads - since you have executed the installer as root) for temporary data (According to https://de.mathworks.com/matlabcentral/answers/229835-is-the-mathworks-folder-necessary-to-run-properly?requestedDomain=www.mathworks.com).
So, yes. It seems like you can delete the folder.
Or just move it to MathWorks.bak and check if Mathworks still works properly. In case everything is working fine, you can delete MathWorks.bak.
A program can do anything when run as sudo and depends only on what the program is designed to do. sudo simply elevates the permissions when running a given command.
I would have thought that the installer would have downloaded everything to /tmp instead of /root/Downloads, but as long as you didn't select /root/Downloads as your installation directory for MATLAB and this is only the temporary download location you can certainly remove it after successfully installing MATLAB to a "typical" location such as /usr/local/MATLAB/R2016a.
I've been stuck on a problem for two days now where the software I'm trying to install will not proceed unless I make a separate user which is non-root.
Keep in mind I'm a big linux noob and not very experienced with the OS.
I make a user called "smrtanalysis" in a group called "smrtanalysis".
I put him in the sudoers file.
I made a folder called smrtanalysis in my home/nick/ directory
I downloaded the software from the PacBio website and put the .run files into this directory I noted above.
I used chmod 777 and chown (to user smrtanalysis) on the directory
noted above, and the .run file
I logged into smrtanalysis user by su smrtanalysis, password, and typed
./smrtanalyis-2.2.0.133377.run
the file runs, but then aborts with the following error message:
We recommend running this script as a designated SMRT Analysis user
(e.g. smrtanalysis) who will own all smrtpipe jobs and daemon
processes.
Current user is 'root' (primary group: root)
Installing as 'root' is currently not supported Switch to the desired
user and restart the install. Aborting installation...
Here is the install documentation:
https://github.com/PacificBiosciences/SMRT-Analysis/wiki/SMRT-Analysis-Software-Installation-v2.2.0
It seems pretty straightforward but I can't seem to get it working. If you guys look at the install docs, you'll probably be able to tell me what I'm doing wrong.
Thanks for any help!
Regards,
Nick
change
SMRT_ROOT=/opt/smrtanalysis
on
SMRT_ROOT=/home/nick/smrtanalysis
the rest should be easy.
Be very careful installing binaries from internet, make sure you're confident in the source.
Just don't use root for that, you ran the script as root by accident.
(update: pacbio team can help from the github page at https://github.com/PacificBiosciences/SMRT-Analysis/issues as well.)
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.
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?