Hot answers tagged

5

To see another users sudo permissions you can use: sudo -l -U <user>. Provided you have enough permissions yourself. Or (to answer the question) you can use the su command (aka switch-user). Running it as su - tina will switch to that user and run the login scripts (drop the - to skip this part). You will be prompted for their password. Or, you use ...


4

You need to run the script instead of sourcing it: /path/to/script.sh (without .). When you run . /path/to/script.sh $0 is your current shell, which is presumably in /bin (hence the behaviour you're seeing). Note that it needn't be /bin/bash, the shebang doesn't have any effect when sourcing a script. Lucas' other points are valid, you should use ...


3

No. The mount options trump all. That's what they're for: to ensure that nothing ever gets executed directly from that filesystem. To counter noexec, you can run most programs indirectly by invoking their launcher: If the program is a script (starting with a shebang), invoke the interpreter and pass it the script as its first argument. If the program is a ...


2

You're on the right track with tty, and the -t option gives you just that. However, unless you are actually aiming to get a tty session for interacting, leave this option off of the last ssh command in your chain. In your case you just need it on the first connection: ssh -L 5901:localhost:6000 host1 -t ssh -L 6000:localhost:5901 -N host2 Now when you use ...


2

As the accepted answer already says, you can use yum shell to run multiple commands at once, which is fine for interactive use. But if you want to invoke this command from a script, you can also run it against a file, eg yum shell translist.txt, where the file could contain, for example: remove squid install squid34 run Append the -y switch to assume yes ...


2

As is often the case on Solaris, /usr/bin/egrep is a legacy implementation that isn't POSIX-compliant, while /usr/xpg4/bin/egrep is a POSIX-compliant implementation and has little if anything beyond POSIX. Unless you're running legacy Solaris applications from the pre-POSIX days, make sure that /usr/xpg4/bin is before /usr/bin in your $PATH. GNU tools ...


2

This is the documented behaviour: message Write this message to the log; if not specified, and the -f flag is not provided, standard input is logged. Fortunately, you can add the needed information to the standard input of the logger: log() { { printf "DEBUG: $@" # Prepends the prefix. cat # ...


2

The variable $0 points to the shell script that you execute itself. So if you have a file in that contains this #!/bin/sh echo "$0" and copy it to /bin/my-script and to ~/somewhere/my-script-2, make both copies executable you can observe this behavior (I assume /bin is in your $PATH): $ my-script /bin/my-script $ ~/somewhere/my-script-2 ...


2

Per man visudo, section "Diagnostics": /etc/sudoers.tmp: Permission denied You didn’t run visudo as root. I see nothing in your post to indicate that you did run it as root. Try sudo visudo. Also it looks like you may be getting errors related to sudo itself. Can you sudo ls ~root successfully? You may also want to review the man page, as: ...


2

I strongly doubt that you want to kill that many processes with pids in that range. (Almost) per definition pid 1 is init, you don't want to kill that. In most cases the next many pids are kernel threads, you don't want to kill those either. On my box the first pid assigned to an "ordinary" process is 310 - and I used quotes, because that's a part of ...


1

Haven't tested this myself but this is how I have understood it to be possible. Live boot to server and mount big enough external hard drive where you can store image. Image server's hard drive: dd if=/dev/sdX bs=4k conv=noerror,sync of=/mount_point_of_extHDD/serverIMG.dd Then let's zero out unused blocks: file /path/to/serverIMG.dd Check startsector ...


1

Passing arguments to a function which can be used as $1 or $@ is not the same as reading stdin. You will have to fetch the data from stdin first. The following might not be the ideal solution but gives you a hint: #!/bin/bash log() { read INPUT logger -s -t $(basename $0) "DEBUG: $INPUT" } echo "test" | (log)


1

I would like to believe that it is not installed if so why the system returned java: /usr/bin/java? whereis doesn't resolve the symlink. So if /usr/bin/java still exist, even though the symlink target is broken, it will still return java: /usr/bin/java. I recommend you use type -a java to get the correct result. Please note that the symlink target OR ...


1

You may have to configure Alternatives to point to java, its explained in my link. I have noticed with trying to keep Oracle Java installed over the openjdk that you have to make sure everything is linking correct and running the correct version of java. If using an RPM system machine, I used the steps in the link below for getting it to work. Install ...


1

Untested. Edit your ~/.profile ... if [ -x /bin/bash ]; then exec bash fi


1

I'd suggest two approaches to determine which packages can be removed: do a minimal installation with the RedHat release in question (which you didn't mention, by the way) and only add the packages on top which are mandatorily required for what this machine is intended to do. Then get the listing of all packages by name (so you could easily compare to ...


1

When you install new updates with yum, the original installed packages and binaries are updated. It doesn't keep multiple copies of them around. It does cache various things however. You can use various yum clean options to tidy up some of yum's own cache files. For example, yum clean packages will remove cached packages that have been downloaded, some ...


1

The -A INPUT -s adds a rule for any packets with the source subnets specified on the line. Therefore, in your example, you are logging and dropping all packets that have a source IP address that starts with 255 and all that start with 0, such as 255.1.2.3.4 or 0.56.78.90 The idea here is that there should will never be packets that start with those ...


1

Thanks to Jeff Schaller. His comment lead to a solution to the problem. Is the responselog about 1697659298 bytes in size? May be that procmail is trying to append to a large file and getting backed up on itself. – Jeff Schaller 20 hours ago There is suppose to be a cron job that runs to rotate the log file and keep its size down. Once I fixed that ...


1

The changes to iptables can't be rolled back one by one: you have to reset all the rules and re-apply the ones you need. In your case, you seem to have a clean firewall by default, so all you need to do is: sudo iptables --table nat ---flush This will remove all the rules from the "nat" table.


1

There is no generic way to find this that I know of, i.e. there is nothing in the protocol like "show me all the iscsi initiators you are connected to".



Only top voted, non community-wiki answers of a minimum length are eligible