After installing an rpm package that I built I would like to change some gsettings. I tried doing so in the %post section, but it does not do anything during the install (not even fail).
spec file:
...
%post
echo "test post"
gsettings set org.gnome.desktop.interface cursor-theme 'something-else'
The echo works, and if I manually type the gsettings command into the terminal it works, but during the installation the command does not work. Any ideas?
Aaron is correct in their comment: Even if you can successfully run gsettings in your %post script, you'll be changing settings for the root user.
If you want to change configurations for some other user in an automated fashion, you could drop a script into /etc/profile.d; these scripts are run for new login shells, which will include someone logging into an X session.
You would want to add some conditionals around your gsettings statement to ensure that it only runs successfully once: if it runs on every login, you've made it impossible for someone to undo this particular configuration change, which can be a frustrating experience.
I would argue that this is better solved via documentation ("After installing this package, here's how to activate the new cursor theme...").
Related
I'm new to linux coding and have just been given an account on a server at work. I don't have sudo permissions. For some unknown reason, the 'screen' program has suddenly stopped working. Every time I try to open a screen session I get the following error
Can't locate local/lib.pm in #INC (you may need to install the local::lib module) (#INC contains: /home/user/perl5/lib/perl5/x86_64-linux-thread-multi /home/user/perl5/lib/perl5 /home/user/miniconda3/lib/site_perl/5.26.2/x86_64-linux-thread-multi /home/user/miniconda3/lib/site_perl/5.26.2 /home/user/miniconda3/lib/5.26.2/x86_64-linux-thread-multi /home/user/miniconda3/lib/5.26.2 .).
BEGIN failed--compilation aborted.
I've tried opening up my .bash_profile and .bashrc to delete any lines referring to perl or the local::lib, and I don't have permissions to install the local::lib myself. I've tried navigating to the directories listed in the error message but they also don't exist. I also tried reinstalling perl and screen into a conda environment but screen needs to be activated before the environment so I just got the same message. Both perl and screen are still installed as I can print the version.
I have no idea why screen suddenly stopped working as I don't think I did anything, and it was working perfectly fine for the first few weeks. Any ideas/help would be much appreciated!
See #dave-mitchell's comments to what local::lib is, but as for how to solve the problem, you'll probably need to install local::lib yourself in your home directory. This does not require administrative access using the bootstrap method as outlined in the local::lib documentation:
https://metacpan.org/pod/local::lib#The-bootstrapping-technique
Following that, cpanminus (cpanminus) should be able to install most perl modules using the --local-lib option as needed.
However, if this is simply a problem with screen itself not working, and you don't care about perl modules per se, then I would recommend installing tmux as an alternative to screen which is also possible to do without administrative privileges (see this superuser question) and is widely considered to be a superior option
This is a simple and perhaps forehead-slapping obvious question, but I still venture to ask it. It is part of a larger effort to troubleshoot a problem I have with vim-fsharp (see github repo here), where I continually get error messages like "Error detected while processing function fsharpbinding#python#OnBufWritePre" and a number of broken pipe errors. I have tried to uninstall and re-install the plugin a few times and with different methods, but none have worked so far, so I'm trying to reconstruct my install process in minutae.
I have also tried to ensure that I have the proper privileges and have run all possible commands with sudo.
My question is now regarding the third point in the installation instruction "Run make inside the vim directory." I'm not sure I understand what the vim directory in this context is. Is it ~/.vim or ~/.vim/bundle/vim-fsharp? And does this mean that I do the following (after having ensured that I have both pathogen and syntastic and run git clone https://github.com/fsharp/vim-fsharp.git): cd vim-fsharp && sudo make?
Run make inside the vim directory.
make needs a Makefile. Since you are unlikely to have one in ~/.vim/ and there's one in ~/.vim/bundle/vim-fsharp you must logically do $ make in the latter:
$ cd ~/.vim/bundle/vim-fsharp
$ make
If I read the Makefile right you don't need sudo.
I have repackaged a Bash RPM to include automatic logging to syslog. I am trying to work out a way to set this up so that it is used ONLY when a user or service account runs a command as root. The option I'm looking at is installing this version of Bash to an alternate location, and then pointing root to use that version as it's default shell.
Can someone go through the process of installing this RPM to an alternate path and associating the root account to it as the default shell? I have been having difficulty finding a way to do this when searching online.
Since you are repackaging the RPM, it is probably best to change the destination path directly in the RPM.
As for the default shell, run chsh -s /path/to/your/bash root to change it.
Be aware that this solution may not work for all purposes though. For example, running a script that starts with #!/bin/bash will still execute it with /bin/bash instead of your default login shell.
I've got an SVN instance installed on a free EC2 AWS server. In short: I'm using LAMP.
Using what I read in this article and encountered the "you need a TTY" error as mentioned in the comments. I followed the second resource and it cleared the error message, but doesn't seem to be executing the script. When I manually run the script, however, it works.
Any clue what I'm missing?
When I followed the second resource to fix the TTY error I changed the contents of my /svn/repository/hooks/post-commit script from:
#!/bin/bash
sudo /usr/local/bin/svn-post-commit-update-mysite 1>&2
to:
#!/bin/bash
su –session-command=”/usr/local/bin/svn-post-commit-update-mysite 1>&2″ dynamic &
First possible issue:
You cannot rely on the value of the $PATH variable inside the hook. This means you need to specify complete paths for all executables.
In particular, "su" is a program located in "/bin/sh" in most distributions. To be sure, type
type su
Next possible issue:
Is your subversion server being run as root? su will try to ask for password if run by other users, and will fail if it's not being run interactively - even if the user is in the sudoers file!
If you are using Apache+DAV, this means the apache service must be run as root for this to work (instead of www-data), which is a serious security problem.
You probably don't need to use su or sudo at all if all of the files are owned by the same user (www-data, for instance). You can change the ownership of the site files with something like
sudo chown -R www-data:www-data /var/www/<my-project>
And then remove the sudo and su from both the hook and the svn-post-commit-update-mysite file.
My best guess would be that something in your script depends on the PATH environment variable. Subversion runs hooks in an empty environment for security reasons. So you need to either setup the environment in your shell script or use absolute paths.
You might want to read the Subversion book entry on implementing hook scripts. The particular issue I mentioned is explained in the information block.
Is there a commonly used approach for displaying 'how to get started' instructions to a user after a .deb installer has finished installing a package?
I need an approach that works for users working via a terminal as well as from a desktop environment.
Server admins will probably know to check for a README file but many others won't.
I'd suggest running the "tty" command from your postinstall script. That will tell you if you have a tty and are running as a terminal program. Once you know that you could either "more" a readme file if you're running in terminal mode or you could call "gnome-text-editor" if not. You might also want to put in some detection to check "/etc/lsb-release" so that you know what distribution your .deb is being installed on and which editors will be suitable.
I use the tty command like Benj suggested, but I use the dialog command to display post install chatter if its available on the system.
Try this command:
dialog --backtitle "All done" --title "Installation complete" --textbox /etc/passwd 0 0
... but replace /etc/passwd with your README of choice. Its a much nicer way to scroll through information.
After a bit of experimentation it looks like I can detect how the .deb package has been installed by checking the value of the DEBIAN_FRONTEND variable in the postint.sh script. When run from the desktop it contains the value 'gnome', but when run via dpkg from the command-line it isn't set, so something like this might work:
HELP_URL="http://mysite.com/help.html"
if [ "$DEBIAN_FRONTEND" = "gnome" ]; then
nohup gnome-www-browser $HELP_URL &
else
echo For help visit $HELP_URL
fi