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.)
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'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 making a simple game for Ubuntu and to update the highscore list, it needs a single file at runtime, called 'highscores.bin'.
I wish to put this file at
/home/(USER)/.game_name
I've researched a little and found that from inside a Makefile i can get the environment variable $USER.
So in the Makefile, at the 'install' target, i've added:
mkdir -p $(DESTDIR)home/$$USER/.game_name
But when i run 'sudo make install', the Makefile installs it as:
/home/root/.game_name
How can i get the (non-root) user name in a Makefile?
P.S.: I'm writing the Makefile by hand. No ./configure
P.S.2: I dont want to do
mkdir -p ~/.game_name
because i want to be able to change DESTDIR if i want to install to a temporary directory.
Well, if you want that file during runtime I would recommend that you create it during runtime. The Makefile is considered only during compile time. This is obviously a problem if the program is compiled and then executed by different users, some of which may not even exist at compile time.
During runtime you can get the home directory as shown here (if you are using C/C++). Then you can check for existance of the highscore folder/file and create it if you need to. If you want a highscore file for all users, you should put it in the home directory of a special user, but rather somewhere else in the file system. This is for example done by the game xjump.
And about your Makefile, the $USER variable is translated to root because of the sudo command on
sudo make install
The user actually running make is the superuser: root.
You want to install your program for every users? So it's better if you create the /home/user/.game_name directory when the user run the game, not when root installs it. Otherwise, only the user who call sudo make install will have it's highscore list. If you have only one user, do not install it system-wide, but in the user directory.
I suggest to initialize users files at game first run. So every users, even users that didn't exist when the game was installed, can have their highscore list. You can add the initializing code into your game (c++, java or anything else) or just call an external script that does it (not so elegant). Avoid to create user-related files at installation time.
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?