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.
Related
I'm having an issue with WSL2:
$ where b4a
/usr/local/bin/b4a
$ b4a new
/usr/local/bin/b4a: 1: Not: not found
Even though where finds commands, I can't run them. And it's not a PATH issue either:
echo $PATH
/usr/local/sbin:/usr/local/bin:[...]
And b4a isn't the only command with this problem. What could be the cause? My distribution is Debian 10 and host is Windows 10.
Not necessarily a full answer, but hopefully the troubleshooting methods you need to arrive at a solution ...
Note that it doesn't say that the command itself isn't found. For instance, if you run:
# lllllllllll
lllllllllll: command not found
That's truly a command not found. This is different. While I don't (yet) know the exact cause, this seems closer to the issues we might see with improperly quoted paths with spaces in a shell script.
You mention that other commands have this problem -- Is there something in common with the commands that don't work properly? Is it possible that they are all shell scripts?
Try several things to debug:
Start WSL without your startup profile. It's very likely that something (or you) added a line that is causing problems. From PowerShell or CMD:
wsl ~ -e bash --noprofile --norc
b4a
If that works, then there's a problem in one of your startup files that you'll need to debug. Look for anything modifying environment variables without proper quoting, especially the PATH. WSL automatically appends the Windows path to your Linux path to make it easy to run Windows commands, but the fact that almost every Windows path has spaces in it can cause problems for unsuspecting scripters that don't take this corner case into account.
Having a space in a path is fully allowed in Linux, but some scripts just don't handle it properly.
If the command that is failing is a shell script, trying starting it with:
bash -x /usr/local/bin/b4a
Or even start WSL with wsl ~ -e bash -x to see all trace output from the shell.
In this case, you'll be looking for some problem in the script right around where it actually fails.
If all else fails, you can disable WSL's PATH modification via its config file:
sudo -e /etc/wsl.conf
Add the following:
[interop]
appendWindowsPath = false
Then exit Debian, run wsl --shutdown and restart Debian. Try the b4a command again.
If this works, then the problem is almost certainly due to some problem in the PATH quoting in these commands. I don't recommend it as a permanent solution since you will have to type out the full path of Windows applications each time you want to run them.
As a workaround for a problem that I face when deploying code using central version control throughout various sites in the company I work, I need, in all sites, to run Ruby from (say):
#!/foo1/bin/ruby -w
However, in just 1 location, ude to an I.T. issue, which may or may not be resolved, I need to use (say):
#!/foo2/bin/ruby -w
This needs to work for ALL users in ALL sites, and I cannot enforce the setup of environment variables. One can of course, use a bash script to split the 2, (a bash script calling either of the locations), but I was hoping for just 1 process, and 1 script. Any ideas?
There are many options to solve that but the simples that I'm familair with is:
Make sure that ruby is accesible by the PATH environment variable.
Instad of using the full path to ruby you can use the /bin/env command that comes in all Linux bundles:
#!/bin/env ruby
Running Ubuntu 14.04, and I have a script that is being run automatically when I boot the machine. For the life of me, I can't remember how or where I did this.
I already checked:
upstart (which doesn't seem to be available here, anyway)
/etc/rc.local
crontab (with #reboot)
/etc/init
/etc/init.d
.config/autostart (doesn't exist btw)
It's a script of my own, so it's not some kind of malicious virus or malware or anything. I just can't remember how I did this, and would like to know.
It has a distinct name, e.g. like ~/MyScriptXYZ.sh so I could search for that, IF I know how or where..?? (I'm a novice linux user)
A few other places you can look:
crontab -e as your own user and as root (local user crontab)
/etc/profile.d/ or /etc/profile
~/.profile
~/.bashrc
The last ditch attempt you can do is to cd / && grep -R "MyScriptXYZ" as root - this will take a while but will search all files on your computer for that reference :)
So I stumbled across this question and I managed to solve it for myself:
I was using Ubuntu (chroot) through the Linux Deploy Android app and I also couldn't find it. So to make the answer complete: Use pstree to locate and trace what is currently running and see where it's originating from.
Following Basile Starynkevitch's advice I managed to solve it by going to:
/home/[user]/.config/lxsession/LXDE/autostart and find it the code I added a while ago.
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.
I am trying to give a non-root user the ability to run mercurial commands from the shell. When I log in as the user and type "hg", I get this message:
abort: couldn't find mercurial libraries in [/usr/local/bin /usr/lib/python24.zip /usr/lib/python2.4 /usr/lib/python2.4/plat-linux2 /usr/lib/python2.4/lib-tk /usr/lib/python2.4/lib-dynload /usr/lib/python2.4/site-packages /usr/lib/python2.4/site-packages/Numeric /usr/lib/python2.4/site-packages/gtk-2.0]
(check your install and PYTHONPATH)
I do not have this problem as the root. I can run mercurial commands from any directory.
My problem is that I'm not very familiar with Linux at all, and so I don't know exactly how I'm supposed to change my PYTHONPATH variable (if indeed that's what I'm trying to do). I don't even know where the PYTHONPATH variable is being stored to see what's written there now.
Can someone tell me where the PYTHONPATH (or even regular PATH) environment variable is stored in Linux, and what steps I might take to remove the error method I'm getting above? If it helps, I'm using Putty and SSH to access the server.
Thanks! :)
The PYTHONPATH is just an environment variable that gets prepended to the python's internal search path. To see what is in there, do the following in python shell:
>>> import sys
>>> sys.path
It should print something like:
['', '/usr/lib64/python27.zip', '/usr/lib64/python2.7', '/usr/lib64/python2.7/plat-linux2', '/usr/lib64/python2.7/lib-tk', '/usr/lib64/python2.7/lib-old', '/usr/lib64/python2.7/lib-dynload', '/usr/lib64/python2.7/site-packages', '/usr/lib64/python2.7/site-packages/PIL', '/usr/lib64/python2.7/site-packages/gst-0.10', '/usr/lib64/python2.7/site-packages/gtk-2.0', '/usr/lib64/python2.7/site-packages/webkit-1.0', '/usr/lib64/python2.7/site-packages/wx-2.8-gtk2-unicode', '/usr/lib/python2.7/site-packages', '/usr/lib/python2.7/site-packages/setuptools-0.6c11-py2.7.egg-info']
In practice, I would guess your shell is bash so the places where the environment variables can be set are:
/etc/profile, /etc/bashrc, ~/.profile and ~/.bashrc - the first 2 being system wide and the latter per user.
For further explanation, see this blog article abour bashrc and profile
EDIT
To fix this, the probably the easiest way is to install Mercurial via pip (I am assuming that you do not have Mercurial in the official repository for your Linux distribution, but usually python-setuptools or similar, that provides easy_install is). See this question for instructions.