I have created a simple bash script to start capturing traffic from all interfaces I have in my Linux machine (ubuntu 22), but this script should stop capturing traffic 2 hours after the machine has reboot. Below is my bash script
#!/bin/bash
cd /home/user/
tcpdump -U -i any -s 65535 -w output.pcap &
pid=$(ps -e | pgrep tcpdump)
echo $pid
sleep 7200
kill -2 $pid
The script works fine if I run it, but I need to have it running after every reboot.
Whenever I run the script, it works without problem
user#linux:~$ sudo ./startup.sh
[sudo] password for user:
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 65535 bytes
1202
35 packets captured
35 packets received by filter
0 packets dropped by kernel
but when I set it in the crontab as
#reboot /home/user/startup.sh
it does not start at reboot. I used ps -e | pgrep tcpdump to make sure if the script is running but there is not an output, it seems that it is not starting the script after the reboot. I don't know if I need to have root permissions for that. Also, I checked the file permission, and it has
-rwxrwxr-x 1 user user 142 Nov 4 10:11 startup.sh
Any suggestion on why it is not starting the script at the reboot?
Suggesting to update your script:
#!/bin/bash
source /home/user/.bash_profile
cd /home/user/
tcpdump -U -i any -s 65535 -w output.pcap &
pid=$(pgrep -f tcpdump)
echo $pid
sleep 7200
kill -2 $pid
Suggesting to inspect crontab execution log in /var/log/cron
The problem here was that even though the user has root permission, if an script needs to be run in crontab at #reboot, crontab needs to be modified by root. That was the only way I found to run the script. As long as I am running tcpdump, this will require root permission but crontab will not start it at the boot up if it is not modified by sudo.
wsl -h shows the following:
--exec, -e <CommandLine> Execute the specified command without using the default Linux shell.
-- Pass the remaining command line as is.
What does "without using the default Linux shell" mean (i.e. what else is it going to use, if not the default shell!?)?.
Additionally, by way of an example, I now have three possible ways to run Linux ls from my PowerShell prompt (i.e. this will not be Get-ChildItem aliased to ls, but instead a Linux command via WSL):
PS C:\> wsl -e ls # Alternatively, wsl --exec ls
PS C:\> wsl -- ls
PS C:\> wsl ls
But all outputs appear to be the same. How would you explain the differences between these three ways of running a WSL Linux command from a PowerShell prompt?
I think it means wsl runs the command directly, instead of spawning a shell process to run the command.
For example, if I run :
wsl -e sleep 10
From another terminal, I have :
root 1482 1 0 11:32 tty3 00:00:00 /init
ubuntu 1483 1482 0 11:32 tty3 00:00:00 sleep 10
We can see /init is the parent of sleep 10, without a shell in between.
A cool trick is using this to set the X11 $DISPLAY variable, letting you use windows terminal to get remote shells using WSLG.
# in microsoft terminal or powershell use this command line
wsl.exe -- ssh -a -X -Y $hostname
then on the remote system
# DISPLAY will show something like localhost:10.0 on the remote system
echo $DISPLAY
# use a program like xeyes to test
xeyes
Im currently logged in as admin and I want to edit the /etc/hosts file which required root access.
I'm not able to make the changes. The script gets executed sucessfully but the changes arent made.
My Script - Runs Sucessfully when executed from terminal
sudo -s
echo "127.0.0.1" >> /etc/hosts
su admin
sudo -s - switches to root without password when executed from terminal
su admin - switches back to admin user when run on terminal
My /etc/hosts file remains empty after running the script
There is no need to actually switch your user within the script.
Also, you can't echo something as root like that because the redirect (>>) is executed by the shell.
A possible workaround is using tee:
echo "127.0.0.1" | sudo tee -a /etc/hosts
Further explanation:
tee basically takes the data from the standard input and writes it either to the standard output, or to a file. For more information see the commands manual ($ man tee)
I have a root server where I disabled login via user root and created another user that is in the sudoer list. So when I want to work on the server I do:
ssh myusername#IP_ADDRESS
On the server:
sudo su
enter my password to get root rights. This worked fine for 6 months now. Today I get this message when doing sudo su:
sudo: no tty present and no askpass program specified
What the hack is happening? What does this error mean and why do I get it?? Without root rights I cannot do so much on the server. Any idea how to fix this?
sudo tries to open /dev/tty for read-write and prints that error if it fails. You've indicated in comments that /dev/tty is missing on your system.
Sudo has an option -S to read the password from standard input instead of /dev/tty. You should be able to run sudo -S to become root.
Regarding how to recover /dev/tty, It's possible that rebooting the server would be sufficient; the system might recreate all devices in /dev during bootup. Alternately, to create a device, you use the mknod command, but you need to know the correct major and minor numbers for the tty device. On an Ubuntu system I have available, I see these entries in /dev:
crw------- 1 root root 5, 1 Apr 16 18:36 console
crw-rw-rw- 1 root tty 5, 2 Sep 24 15:35 ptmx
crw-rw-rw- 1 root tty 5, 0 Sep 24 14:25 tty
In this case, the major number is 5 and the minor number is 0. /dev/console and /dev/ptmx have the same major number. So I'd inspect /dev/console or /dev/ptmx to find the correct major number, then run:
mknod /dev/tty c major 0
where "major" is the correct major number.
After recreating /dev/tty, make sure the permissions are correct:
chmod 666 /dev/tty
It fails, because sudo is trying to prompt on root password and there is no pseudo-tty allocated.
You've to either log-in as root or set-up the following rules in your /etc/sudoers
(or: sudo visudo):
# Members of the admin group may gain root privileges.
%admin ALL=(ALL) NOPASSWD:ALL
Then make sure that your user belongs to admin group (or wheel).
Ideally (safer) it would be to limit root privileges only to specific commands which can be specified as %admin ALL=(ALL) NOPASSWD:/path/to/program
One thing to check is whether the OS thinks that the various processes "have a tty". If you are still having problems, it's probably worth doing this in both the shell within which you run ssh and the shell within which you run sudo. The easy way to check is the command "tty" - if it returns "not a tty", that shell doesn't have a "controlling tty" and cannot open /dev/tty even if it exists in the file system.
Various circumstances can cause a shell to not have been run using a controlling tty, and some of them do not provide any visible warning. E.g., I recently ran into a problem on High Sierra with Emacs shell windows (Cannot open pty under Mac OS High Sierra) -- High Sierra uses a different mechanism for allocating pty's than earlier Mac OS X releases, so if your code isn't reconfigured for it, it will fail to allocate a pty.
I have a script that runs from udev when I plug in my external drive. It always worked. But after upgrading from Linux 3.8/Xorg 1.12/Mint 14 (Ubuntu 12.10 compatible) to Linux 3.11/Xorg 1.14/Mint 16 (Ubuntu 13.10 compatible), it doesn't work anymore.
The script still runs, but none of the commands that require the display work. I figured that out by quitting the udev daemon and manually run udevd --debug for verbose output (more below).
This script used to work in Mint 14/12.10:
export DISPLAY=:0
UUID=$1
DEV=$2
notify-send -t 700 "mounting $DEV ($UUID)"
gnome-terminal -t "Backing up home..." -x rsync long line of data
zenity --warning --text="Done."
But not anymore in Mint 16/13.10. In case you are wondering about possible solutions, I gradually added stuff and now it looks like this:
export DISPLAY=:0.0
xhost +local:
xhost +si:localuser:root
xhost +
DISPLAY=:0.0
export DISPLAY=:0.0
UUID=$1
DEV=$2
notify-send -t 700 "mounting $DEV ($UUID)"
gnome-terminal -t "Backing up home..." -x rsync long line of data
zenity --warning --text="Done." --display=:0.0
But it still doesn't work. udevd --debug still shows this:
'(err) 'No protocol specified'
'(err) ''
'(err) '** (gnome-terminal:24171): WARNING **: Could not open X display'
'(err) 'No protocol specified'
'(err) 'Failed to parse arguments: Cannot open display: '
'(err) 'No protocol specified'
'(err) ''
'(err) '** (zenity:24173): WARNING **: Could not open X display'
'(err) 'No protocol specified'
'(err) ''
'(err) '(zenity:24173): Gtk-WARNING **: cannot open display: :0.0'
'(err) 'No protocol specified'
Note that any bash logic works. Echoing test vars to >>/tmp/test.log works. It's just accessing the display that does not work anymore.
This is driving me crazy. What is the correct way to achieve this now?
Update 2013-12-20
So, in the previous Ubuntu, X commands would automatically find it's way to the current X using user.
Now, I seem to need these two things every time:
On the X using user:
xhost +si:localuser:root
On the root/udev side:
Copy X using users' ~/.Xauthority file to /root
This 'feels' like a step back in time. This only works scripted when I log in as the same user everytime, so I can copy the .Xauthority file from that users' home when the script executes.
What 'trick' did the old Ubuntu use to have this done auto'magic'ally?
Ok, I'm writing this answer to try and clarify the security model of the X server, as I understand it. I'm not an expert on the subject, so I may have got some (many?) things wrong. Also, many things are different in different distributions, or even different versions of the same distribution, as the OP noted.
There are two main ways to get authorized to connect to the X server:
The xhost way (Host Access): The server maintains a list of hosts, local users, groups, etc. that are allowed to connect to the server.
The xauth way (Cookie based): The server has a list of randomly generated cookies, and anybody showing one of these cookies will be granted access.
Now, the distribution specific stuff...
When the X server is launch by the start-up system, it is usually passed a command line of the form -auth <filename>. This file contains a list of initial cookies to be used for authorization. It is created before the X server is run using the xauth tool. Then just after the X server, the login manager is launch, and it is instructed to read the cookie from this same file, so it can connect.
Now, when user rodrigo logs in, it has to be authorized to connect to the server. That is done by the login manager, and it has two options:
It does the equivalent to: xhost +si:localuser:rodrigo.
It generates another cookie, adds it to the server and passes it to the user. This passing can be done in two ways:
It is written in the file $HOME/.Xauthority (home of the new user).
It is written somewhere else (/var/run/gdm/auth-for-rodrigo-xxxx) and the environment variable XAUTHORITY is set to the name of that file.
Also, it can do both things. Some login managers even add the root user to the list of authorized users by default (as if xhost +si:localuser:root).
But note that if you are not authorized to connect to the X server, you cannot add yourself to the list (running xhost + for example). The reason is the same as why you cannot open a house doof from the outside without a key... That's true even if you are root!
Does it mean that the root user cannot connect to the server? Absolutely not! But to get to that first you have to know how is the logged user configured to connect to the server. For that run as the logged user:
$ xhost
It will show a message and the list of authorized users, hosts or groups, if any:
access control enabled, only authorized clients can connect
SI:localuser:rodrigo
Then run:
$ echo $XAUTHORITY
To see where the authorization file is saved. If it is empty, then it will be ~/.Xauthority. Then:
$ xauth list :0
To see the list of your authorized cookies.
Now, if there are any cookie in the server, the root user should be able to connect making the XAUTHORITY environment variable point to the right cookie file. Note that in many setups, the cookie of the login manager is also kept around. Just look for it!
Another possibility for root access is to modify the Xsession files to add the command xhost +si:localuser:root and get permanent access. The details vary with the particular program used, but for gdm you would simply add an executable script in /etc/gdm/Init/ with the xhost command and it will be run automatically in the next boot.
PS: You can check your root access to the X server with sudo -i, but note that some sudo configurations may keep the DISPLAY, XAUTHORITY or HOME variables and modify the results of the tests.
EXAMPLE: This script should be able to connect you to the X server as root
export DISPLAY=:0
export XAUTHORITY=`ls /var/run/gdm/auth-for-gdm-*/database`
xrandr #just for show
Naturally, the path for the XAUTHORITY variable will depend on what login manager you are using (greeter). You can use the user file (you say it is in /home/redsandro/.Xauthority but I'm not so sure). Or you can use the greeter cookie. To get the greeter cookie you can use the following command:
$ pgrep -a Xorg
Which in my system gives:
408 /usr/bin/Xorg :0 -background none -verbose -auth /var/run/gdm/auth-for-gdm-gDg3Ij/database -seat seat0 -nolisten tcp vt1
So my file is /var/run/gdm/auth-for-gdm-gDg3Ij/database. The gDg3Ij is random and changes every time the server is restarted, that's why the ls ... trick.
The nice thing of using the GDM cookie instead of the user is that it does not depend on the user logged in. It will even work with no user at all!
UPDATE: From your latest comment I see that your X server command is:
/usr/bin/X :0 -audit 0 -auth /var/lib/mdm/:0.Xauth -nolisten tcp vt8
So there is the name of the cookie used to start the login manager. If I'm correct, that should be available all the time, if you are able to read the file. And you are root, so, the following lines should be enough to get you access to the display as root:
export DISPLAY=:0
export XAUTHORITY=/var/lib/mdm/:0.Xauth
zenity --info --text 'Happy New Year'
A quick search turned up the following:
X authentication is based on cookies -- secret little pieces of random
data that only you and the X server know... So, you need to let the
other user in on what your cookie is. One way to do this is as
follows: Before you issue the su or sudo (but after having ssh'ed into
the remote system if you are using ssh), request the cookie for the
current DISPLAY that's connecting to your X server:
$ xauth list $DISPLAY You'll get something like
somehost.somedomain:10 mit-magic-cookie-1
4d22408a71a55b41ccd1657d377923ae
Then, after having done su, tell the new user what the cookie is:
$ xauth add somehost.somedomain:10 MIT-MAGIC-COOKIE-1
4d22408a71a55b41ccd1657d377923ae
(just copy and paste the output of the above 'xauth list' onto 'xauth
add') That's it. Now, you should be able to start any X application.
For reference, here is the origin http://www.linuxquestions.org/questions/linux-newbie-8/xlib-connection-to-0-0-refused-by-server-xlib-no-protocol-specified-152556/
This is not pretty, but I have not seen any solutions yet. So it's the best one so far.
On the X using user:
xhost +si:localuser:root
On the root/udev side:
Copy X using users' ~/.Xauthority file to /root (* see note below)
Now it works. Try zenity --warning --text=Hooray
This only works when you know which user is going to be logged into X. So it's only acceptable when the computer is being used by a single user with a single user account.
*) Note
This is notable, because I tried the documented ways of xauth merge /home/redsandro/.Xauthority and $XAUTHORITY=/home/redsandro/.Xauthority. These documented methods just plain do nothing these days, even if root has permission to read it. You need to literally the whole .Xauthority file in stead of just pointing to it.
Newer versions of Ubuntu use different display managers, so you have to know which one you are using.
In Rodrigo's post, there is a hint showing how to discover it, using this command:
ls /var/run/gdm/auth-for-gdm-*/database
To check this, list the /var/run directory and use the "pgrep -a Xorg" command.
In Ubuntu 16* it'´s using sddm, so, you can use
ls /var/run/sddm* to export the XAUTHORITY variable.
The script would be like this:
#!/bin/bash
export DISPLAY=:0
export XAUTHORITY=`ls /var/run/sddm*`
HDMI_STATUS="$(cat /sys/class/drm/card0-HDMI-A-1/status)"
USER="your username"
export XAUTHORITY=/home/$USER/.Xauthority
export DISPLAY=:0
if [ "$HDMI_STATUS" = connected ];
then
sudo -u $USER pactl set-card-profile 0 output:hdmi-stereo+input:analog-stereo
else
sudo -u $USER pactl set-card-profile 0 output:analog-stereo+input:analog-stereo
fi
exit 0
then run:
sudo chmod 755 /usr/local/bin/toggle-sound
echo 'ACTION=="change", SUBSYSTEM=="drm", RUN+="/usr/local/bin/toggle-sound"' | sudo tee /etc/udev/rules.d/99-hdmi-sound.rules
sudo udevadm control --reload-rules
I had to use this in Kali Linux 2016 to get it to work:
#!/bin/bash
set -x
xhost local:root
export DISPLAY=:0.0
su root -c 'zenity --notification --text="I am a notification!"'
If calling the script directly from udev doesn't work, why not start a systemd service which calls that script?
Here's my solution:
First is the udev rule that runs media-storage-unplugged.service when a device (or partition) that has ID_PART_ENTRY_UUID is unplugged
/etc/udev/rules.d/storage-unplugged.rules:
ACTION=="remove", KERNEL=="sd[a-z][0-9]", ENV{ID_PART_ENTRY_UUID}=="replace-with-your-uuid", SYMLINK+="storage", RUN+="/usr/bin/systemctl --no-block start media-storage-unplugged.service"
/etc/systemd/system/media-storage-unplugged.service: (service file)
[Unit]
Description=Triggered when storage is unplugged
[Service]
Type=oneshot
ExecStart=/usr/local/bin/storage_unplugged
[Install]
WantedBy=multi-user.target
/usr/local/bin/storage_unplugged (get creative here)
#!/bin/bash
notify-send-to-user "storage unplugged"
exit 0
/usr/local/bin/notify-send-to-user
#!/bin/bash
function ns() {
#Detect the name of the display in use
local display=":$(ls /tmp/.X11-unix/* | sed 's#/tmp/.X11-unix/X##' | head -n 1)"
#Detect the user using such display (NOTE: Didn't work on Arch linux since the "who" command doesn't show which display the user is using)
#local user=$(who | grep '('$display')' | awk '{print $1}' | head -n 1)
#Statically assign user:
local user="user" # Replace with your user
#Detect the id of the user
local uid=$(id -u $user)
sudo -u $user DISPLAY=$display DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/$uid/bus notify-send "$#"
}
ns "$#"
Adapt this method to your needs :)