I need to limit file size when I run "tcpdump -w 1.pcap". I try to do this with the key "-C", but when I add it I get error "permission denied". So:
> sudo tcpdump -w 1.pcap
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
^C821 packets captured
847 packets received by filter
24 packets dropped by kernel
But:
> sudo tcpdump -C 100 -w 1.pcap
tcpdump: 1.pcap: Permission denied
I run the command from my home directory and I tried to remove and create the file before running the command with different permissions, finally I have:
-rwxrwxrwx 1 root root 0 Aug 5 10:30 1.pcap
or
-rwxrwxrwx 1 fd8 users 0 Aug 5 10:30 1.pcap
Could you suggest why in the second case I can't write to the file?
You need to do -Z root. Read the man page:
-Z Drops privileges (if root) and changes user ID to user and the group ID to the primary group of user.
This behavior is enabled by default (-Z tcpdump), and can be disabled by -Z root.
I experienced similar issues on Ubuntu 12.04 LTS and my case was fixed as below procedures.
sudo apt-get install apparmor-utils
The aa-complain command which referred by user2704275 is included in this package.
If your environment is RedHat/CentOS distro, you can same command by yum.
sudo aa-complain /usr/sbin/tcpdump
This will change AppArmor mode of tcpdump from "enforce" to "complain".
You can check AppArmor status in /sys/kernel/security/apparmor/profiles.
Then I can success to get tcpdump with sudo.
After getting tcpdump, for security reason, you might revert apparmor status to previous mode as below command.
sudo aa-enforce /usr/sbin/tcpdump
Regards.
I experienced similar problems when I tried to read from file, like
tcpdump -r example.cap 'icmp[icmptype] = icmp-echo'
For me AppArmor caused the problem I had to switch from 'enforcement' mode to 'complain' mode on 'tcpdump'. Run the following command as root:
aa-complain /usr/sbin/tcpdump
Related
I am creating a tcpdump file using "tcpdump tcp -w tcp1" but I can't use the -r function to read the file as it says "permissions denied". I used chmod to try and change permissions even changed group permissions and still now affect. Help! Thank you
ubuntu 20.04
root#ubuntu:~# tcpdump tcp -w tcp1
tcpdump: listening on ens33, link-type EN10MB (Ethernet), capture size 262144 bytes
^C
985 packets captured
985 packets received by filter
0 packets dropped by kernel
root#ubuntu:~# tcpdump -r tcp1
tcpdump: tcp1: Permission denied
root#ubuntu:~#
It's to do with AppAmour - you'll need to disable it first.
There are instructions here: https://www.xmodulo.com/disable-particular-apparmor-profile-ubuntu.html
I hard to restart by box, just restarting the service didn't seem to do it.
I created a simple systemd unit file(sysupdate.service) with following content to automate system updates, but got frustrated by complexity.
/etc/systemd/system/sysupdate.service:
[Unit]
Description=update system preferably after dnfdragora finished checking update
After=syslog.target network.target network-online.target auditd.service
[Service]
StandardInput=null
ExecStart=/mnt/0/sysupdate.sh
[Install]
WantedBy=multi-user.target
sysupdate.sh:
#!/bin/sh
exec &>> /mnt/0/sysupdate.log
echo $(date)
sudo dnf upgrade -y
echo '$?':$?
sudo youtube-dl -U
echo '$?':$?
sudo systemctl stop bluetooth.service
sudo systemctl disable bluetooth.service
sudo systemctl status bluetooth.service
echo '$?':$?
echo $(date)
The normal user has write privilege inside /mnt/0/.
sysupdate.sh was set "chmod uo+x".
Every time I commented out "service Type", "After" or "user" in service file, I always do:
sudo systemctl daemon-reload
The expected log file "/mnt/0/sysupdate.log" never gets created.
Why such simple automation is so difficult to get done?!
Latest status:
Even I executed as root the 2 lines of code given by "journalctl -xe":
SELinux is preventing (pdate.sh) from execute access on the file sysupdate.sh.
***** Plugin catchall (100. confidence) suggests **************************
If you believe that (pdate.sh) should be allowed execute access on the sysupdate.sh file by defa
Then you should report this as a bug.
You can generate a local policy module to allow this access.
Do
allow this access for now by executing:
# ausearch -c '(pdate.sh)' --raw | audit2allow -M my-pdatesh
# semodule -X 300 -i my-pdatesh.pp
There's still permission denied error in journal log.
I temporarily got it work by setting SELinux permissive.
I've recently started using Google's Compute engine for some of my projects the problem is my startup script doesn't seem to work, For some reason my script just doesn't work, the VM has the startup-script metadata and it works fine when I run it manually with:
sudo google_metadata_script_runner --script-type startup
Here is what I am trying to run on startup:
#!/bin/bash
sudo apt-get update
sudo rm -f Eve.jar
sudo rm -f GameServerStatus.jar
wget <URL>/Eve.jar
wget <URL>/GameServerStatus.jar
sudo chmod 7777 Eve.jar
sudo chmod 7777 GameServerStatus.jar
screen -dmS Eve sh Eve.sh
screen -dmS PWISS sh GameServerStatus.sh
There are no errors in the log either, it just seems to stop at the chmod or screen commands, Any ideas?
Thanks!
To add to kangbu's answer:
Checking the logs in container-optimized OS by
sudo journalctl -u google-startup-scripts.service
showed that the script could not find the user. After a long time of debugging I finally added a delay before the sudo and now it works. Seems the user is not registered when the script runs.
#! /bin/bash
sleep 10 # wait...
cut -d: -f1 /etc/passwd > /home/user/users.txt # make sure the user exists
cd /home/user/project # cd does not work after sudo, do it before
sudo -u user bash -c '\
source /home/user/.bashrc && \
<your-task> && \
date > /home/user/startup.log'
I have the same problem #Brina mentioned. I set up metadata key startup-script and value like:
touch a
ls -al > test.txt
When I ran the script above sudo google_metadata_script_runner --script-type startup, it worked perfectly, However if I reset my VM instance the startup script didn't work. So, I checked startup script logs
...
Jul 3 04:30:37 kbot-6 ntpd[1514]: Listen normally on 5 eth0 fe80::4001:aff:fe8c:7 UDP 123
Jul 3 04:30:37 kbot-6 ntpd[1514]: peers refreshed
Jul 3 04:30:37 kbot-6 ntpd[1514]: Listening on routing socket on fd #22 for interface updates
Jul 3 04:30:38 kbot-6 startup-script: INFO Starting startup scripts.
Jul 3 04:30:38 kbot-6 startup-script: INFO Found startup-script in metadata.
Jul 3 04:30:38 kbot-6 startup-script: INFO startup-script: Return code 0.
Jul 3 04:30:38 kbot-6 startup-script: INFO Finished running startup scripts.
Yes. they found startup-script and ran it. I guessed it had executed as an another user. I changed my script like this:
pwd > /tmp/pwd.txt
whoami > /tmp/whoami.txt
The result is:
myuserid#kbot-6:/tmp$ cat pwd.txt whoami.txt
/
root
Yes. It was executed at the / diectory as root user. Finally, I changed my script to sudo -u myuserid bash -c ... which run it by specified userid.
Go to the VM instances page.
Click on the instance for which you want to add a startup script.
Click the Edit button at the top of the page.
Under Custom metadata, click Add item.
Add your startup script using one of the following keys:
startup-script: Supply the startup script contents directly with this key.
startup-script-URL: Supply a Google Cloud Storage URL to the start script file with this key.
It is working. The documentation for the new instance and existing instance as shown in GCE Start Up Script
Startup script output is written to the following log files:
CentOS and RHEL: /var/log/messages
Debian: /var/log/daemon.log
Ubuntu 14.04, 16.04, and 16.10: /var/log/syslog
On Ubuntu 12.04, SLES 11 and 12, and all images older than v20160606:
sudo /usr/share/google/run-startup-scripts
think that you do not need sudo, as well as the chmod 7777 should be 777
also a cd (or at least a pwd) at the beginning might be useful.
... log to text file, in order to know where the script may fail.
I am using SunOS 5.10 Generic_147441-24 i86pc i386 i86pc
if i run
which sudo
i get the below
/opt/sfw/bin
when i run "sudo -l" i get the below
User localuser may run the following commands on this host:
(root) NOPASSWD: /sbin/ifconfig
for "visudo"
visudo
-bash: visudo: command not found
also /etc/sudoers file does not exist in the box.
Please help me configure sudo, how it is possible with out the sudoers file.
Perhaps you should have a look at Sun (Oracle) RBAC for accounts, rather than rely on sudo in Solaris? It is unclear from your post why you must use sudo, but if you are not calling sudo from a script, it might be worth your while to read: http://docs.oracle.com/cd/E23824_01/html/821-1456/rbac-1.html
I've never seen the sudo binary exist in /opt, so my first thought would be that your visudo binary is not in your path, or the sudo package you installed does not contain the visudo binary. Either way you may consider downloading the sudo package again and reinstalling.
To see if your visudo binary exists anywhere:
find / -name visudo -print
If you find nothing, remember you do not explicitly need visudo to use sudo -- it's there as a checkpoint for making sure that you do not save and exit a sudoers file that has errors, thus possibly compromising your ability to edit it again or to break sudo for all users on the host.
Also note that /etc/sudoers can start off empty, just fill it in with your sudo rules. For example, to provide sudo all commands on that host for a user without prompting for a password:
userid ALL=(ALL) NOPASSWD: ALL
That particular user ID can run "sudo -l" to list the sudo rules available to it. You could do this even just to test that sudo is in fact working on your host.
You could easily get the location of the sudoers file from sudo binary itself by doing this
cat $(which sudo) | strings | grep /sudoers
Then, you would know what file to modify.
I'm on Kubuntu 12.04, and after installing mysql via an apt-get (mysql ver: 5.5.35), i'm trying to start mysql service, but I got this error:
sudo service mysql start
start: Job failed to start
So I googled this problem, it says i have to go to the /var/log/mysql/error.log
But my error.log file is empty :(
Then I checked the permissions
:
drwxr-s--- 2 mysql adm 4096 Apr 7 11:21 mysql
-rw-r----- 1 mysql adm 0 Apr 7 11:21 error.log
So I don't know what to do... Why this error ? Why is the error file empty ?
First make a backup of your /var/lib/mysql/ directory just to be safe.
sudo mkdir /home/<your username>/mysql/
cd /var/lib/mysql/
sudo cp * /home/<your username>/mysql/ -R
Next purge MySQL (this will remove php5-mysql and phpmyadmin as well as a number of other libraries so be prepared to re-install some items after this.
sudo apt-get purge mysql-server-5.1 mysql-common
Remove the folder /etc/mysql/ and it's contents
sudo rm /etc/mysql/ -R
Next check that your old database files are still in /var/lib/mysql/ if they are not then copy them back in to the folder then chown root:root
(only run these if the files are no longer there)
sudo mkdir /var/lib/mysql/
sudo chown root:root /var/lib/mysql/ -R
cd ~/mysql/
sudo cp * /var/lib/mysql/ -R
Next install mysql server
sudo apt-get install mysql-server
Finally re-install any missing packages like phpmyadmin and php5-mysql.
My problem was running out of memory. Digital ocean has great instruction for adding swap memory for Ubuntu: https://www.digitalocean.com/community/tutorials/how-to-add-swap-on-ubuntu-14-04
This solved the issue and enabled me to restart the Mysql that otherwise would not start.
Reinstallation will works because it will reset all the value to default. It is better to find what the real culprits (my.cnf editing mistake does happens, e.g. bad/outdated parameter suggestion during mysql tuning.)
Here is the mysql diagnosis if you suspect some value is wrong inside my.cnf : Run the mysqld to show you the results.
sudo -u mysql mysqld
Afterwards, fix all the my.cnf key error that pop out from the screen until mysqld startup successfully.
Then restart it using
sudo service mysql restart
In my case, it simply because the disk is full.
Just clear some disk space and restart and everything is fine.
In most cases, just purging the mysql-server package and re-installing it will do the job.
Run,
sudo apt-get purge mysql-server-5.1 mysql-common
followed by
sudo apt-get install mysql-server
This line did solve the issue in my case,
sudo apt clean
In my case, i do:
sudo nano /etc/mysql/my.cnf
search for bind names and IPs
remove the specific, and let only localhost 127.0.0.1 and the hostname
Check the file permissions, if edited
Fail:
$ sudo chmod 776 /etc/mysql/my.cnf
$ sudo service mysql restart
mysql stop/waiting
start: Job failed to start
Ok:
$ sudo chmod 774 /etc/mysql/my.cnf
$ sudo service mysql restart
stop: Unknown instance:
mysql start/running, process 9564
To help others who do not have a full disk to troubleshoot this problem, first inspect your error log (for me the path is given in my /etc/mysql/my.cnf file):
tail /var/log/mysql/error.log
My problem turned out to be a new IP address allocated after some network router reconfiguration, so I needed to change the bind-address variable.
In my case the problem was the /var/log disk full (check with df -h)
Just deleted some log files and mysql started, no big deal!
The given solution requires enough free HDD, the actual problem was the HDD memory shortage. So If you don't have an alternative server or free disk space, you need some other alternative.
I faced this error with my production server (Linode VPS) when I was running a bulk download into MySQL. Its not a proper solution but VERY QUICK FIX, which we often need in production to bring things UP FAST.
Resize our VPS Server to higher Hard Disk size
Start MySQL, it works.
Login to your MySQL instance and make appropriate adjustments that caused this error (e.g. remove some records, table, or take DB backup to your local machine that are not required at production, etc. After all you know, what caused this issue.)
Downgrade your VPS Server to previous package you was already using
In my case:
restart server
restart mysql
create .socket in directory
I had the same problem. But i discover that my hd is full.
$ sudo cat /var/log/upstart/mysql.log
/proc/self/fd/9: ERROR: The partition with /var/lib/mysql is too full!
So, I run
$ df -h
And I got the message
/dev/xvda1 7.8G 7.4G 0 100% /
Then I found out which folder was full by running the following command on the terminal
$ cd /var/www
$ for i in *; do echo $i; find $i |wc -l; done
This give me the number of files on each folder on /var/www. I logged into the folder with most files, and deleted some backup files, and i continued deleting useless files and cache files.
then I run $ sudo /etc/init.d/mysql start and it work again