My Script currently takes the first user returned from "users" and in testing it worked fine but once i turned it into a login hook it couldn't pickup the user properly.
Is there a way to pickup the user that is logging in?
Using $USER doesnt work either
Ive tried using "/usr/bin/logname" to get the username and that only returns "root"
Have you tried $USER env variable?
MacOS passes the username to the script as the first argument so in bash it would be stored in $1
Related
I want to check if I am using elevated user rights, like running su another_user and seeing my original user name / id.
All I found when researching that topic is either hardcode my own username somewhere, or examples for root user only (id=0).
I think zsh has a variable for that: $DEFAULT_USER, but it's not working in bash.
How can i generate a script that will open up the terminal, login to the local admin account using username and password then make the non-admin user an admin. Like this link where its done manually but i want it done using a script.
I'm not sure if the terminal will take a password or username from a script, if not could someone tell me? obviously the script wont be possible then.
I wanted to create an installation script for my raspberry pi which secures the default installation by configuring/hardening ssh, installing a firewall and fail2ban and finally to get rid off the default user of Raspbian. All other parts work but the final part always shows me an error.
The new user is created and added to the sudo group. After that I want to delete the old user 'pi'. As the script runs with sudo in the user context of 'pi' I thought I could solve this by switching to 'su' but I just get an error that the user couldn't be deleted as it is used by a process:
echo "Enter the new user name? Only lower case letters allowed!"
read user
sudo adduser $user && adduser $user sudo
echo "default user 'pi' will now be deleted"
su -c "deluser -remove-home pi"
If I check with 'users' the user 'pi' is gone but I can still log in with this account. How can I solve this problem inside the script?
I tried the answers I found here: How do I use su to execute the rest of the bash script as that user? and here: https://unix.stackexchange.com/questions/361327/how-to-login-as-different-user-inside-shell-script-and-execute-a-set-of-commands but nothing seem to work. I searched Google but I can't find any solution that works. Is it even possible what I'm trying to?
I usually add set -eux at the beginning of the bash script. This allows to debug and find typos and errors.
Try to switch user inside the script with
sudo -i -u ${user} $(command to delete pi here)
Think i found the cause of the problem. 'set -eux' was a great help:
deluser pi
Removing user `pi' ...
Warning: group `pi' has no more members.
userdel: user pi is currently used by process 445
/usr/sbin/deluser: `/usr/sbin/userdel pi' returned error code 8. Exiting.
I tried ps -fu pi to find the process which causes the trouble: it's /lib/systemd/systemd --user Is there a way to stop this process inside the script?
I was logged in via SSH as the user who was currently logged in.
I enter the remote computer using my admin account.
ssh admin_a#ipaddress
Then proceeded with:
su username_b (current login user)
The result left me in bash-prompt (which I don't understand) as the current user logged in ( tested this by using whoami ).
Q1: When I switch over to the user who is logged in, why does it put me into bash-prompt (i.e. ~bash$ ) - why not ~ username_of_current_user$ ?
After I created the bash script and placed it into the current user's directory - the script is called from launch agents, although it doesn't work.
The error logs showed that one of the variable's output is wrong: whoami = root, when it should = current_user_logged_in.
Q2: Why is the script being called from root?
su - invokes a login shell after switching the user. A login shell resets most environment variables, providing a clean base.
su just switches the user, providing a normal shell with an environment nearly the same as with the old user.
The most obvious example of this is that ~ is root's home directory if you use su -, but your own home directory if you use su.
Depending on your system, it may also mean differences in prompt, PATH, or history file.
For more details:
https://unix.stackexchange.com/questions/7013/why-do-we-use-su-and-not-just-su
* QUICK SOLUTION *
For those of you visiting this page based on the title solely and not wanting to read through everything below, or thinking everything below doesn't apply to your situation, maybe this will help... If all you are looking to do is change a users password on boot and are using Ubuntu 12.04 or similar, here is all you have to do. Add a script to start on boot containing the following:
printf "New Password\nRepeat Password\n" | passwd user
Keep in mind, this must be run as root, otherwise you will need to provide the original password like so:
printf "Original Password\nNew Password\nRepeat Password\n" | passwd user
* START ORIGINAL QUESTION *
I have a first boot script that sets up a VM by doing some configuration and file copies from a mounted iso. Basically the following happens:
VM boots for the first time.
/etc/rc.local is used to mount a CD ISO to /media/cdrom and execute /media/cdrom/boot.sh
The boot.sh file does some basic configuration, copies some files from CD to the VM and should update the users password, using the current password.
This part of the script fails. The password is not updating. I have tried the following:
VAR="1234test6789"
echo -e "DEFAULT\n$VAR\n$VAR" | passwd user
Basically the default VM is setup with a user (for example jack) with a default password (DEFAULT) The script above, using the default password updates to the new password stored in VAR. The script works by itself when logged in, but I cant get it to do the same on boot. I'm sure there is some sort of system policy or something that prevents this. If so, I need some sort of work around. This VM is being mass deployed and is packaged automatically and configured with a custom user password that is passed from the CD ISO.
Please help. Thank you!
* UPDATE *
Oh, and I'm using Ubuntu 12.04
* UPDATE *
I tried your suggestion. The following files directly in the rc.local ie the password does not update. The script is running however. I tested by adding the touch line.
touch /home/jack/test
VAR="1234test5678"
printf "P#ssw0rd\n$VAR\n$VAR" | passwd jack
P#ssw0rd is the example default VM password.
Jack is the example username.
* UPDATE *
Ok, we think the issue may be tied to rc.local. So rc.local is called really early on before run levels and may be causing the issue.
* UPDATE *
Well, potentially good news. The password seems to be updating now, but its updating to something other than what I set in $VAR. I think it might be adding something to it. This is ofcourse just a guess. Everytime I run the test, immediately after the script runs at boot I can no longer login with the username it was trying to update. I know that's not a lot of information to go on, but it's all I've got at the moment. Any ideas what or why its appending something else to the password?
* SOLUTION *
So there were several small problems as to why I could not get the suggestion below working. I won't outline them here as they are irrelevant. The ultimate solution was from Graeme tied in with some other features of my script which I will share below.
The default VM boots
rc.local does the following:
if [ -f /etc/program/tmp ]; then
mount -t iso9660 -o ro /dev/cdrom /media/cdrom
cd /media/cdrom
./boot.sh
fi
(The tmp file is there just to prevent the first boot script from running more than once. After boot.sh runs one, it removes that tmp file.)
boot.sh on the CDROM runs (with root privileges)
boot.sh copies files from the CDROM to /etc/program
boot.sh also updates the users password with the following:
VAR="DEFAULT"
cp config "/etc/program/config"
printf "$VAR\n$VAR\n" | passwd user
rm -rf /etc/program/tmp
(VAR is changed by another part of the server that is connected to our OVA deployment solution. Basically the user gets a customized, well random password for their VM so similar users cannot access each others VMs)
There is still some testing to be done, but I am reasonably satisfied that this issue is resolved. 95%
Edit - updated for not entering the original password
The sh version of echo does not have the -e option, unlike bash. Switch echo for printf. Also the rc.local script will have root privileges, so it won't prompt for the original password. Using that will cause the command to fail since 'DEFAULT' will be taken as the new password and the confirm will fail. This should work:
VAR="1234test6789"
printf "$VAR\n$VAR\n" | passwd user
Ubuntu uses dash at boot time, which is a drop in replacement for sh and is much more lightweight that bash. echo -e is a common bashism which doesn't work elsewhere.