sudo asks for password even if NOPASSWD is set in /etc/sudoers

TL;DR when a script is not marked as executable and you try to run it with sudo, you don’t get the usual -bash: myScript.sh: Permission denied message, you are prompted for a password instead!

This one was very frustrating.

What I wanted to do was to make a user (let’s call him bran) able to execute a specific script (let’s call it /home/hodor/calm_down.sh) without having to provide his password, because the script will be executed by an automated tool (Jenkins).

I reached back to my earlier post about sudo, and updated the /etc/sudoers file so that its User privilege specification section looked like this:

root    ALL=(ALL) ALL
bran    ALL=(hodor)  NOPASSWD:  /home/hodor/calm_down.sh *

The last line gives user bran the ability to run /home/hodor/calm_down.sh as user hodor passing it any number of parameters (*) without having to provide his password (NOPASSWD:).

Saved it, su‘ed into bran, ran

bran@laketower:~$ sudo -u hodor /home/hodor/calm_down.sh "it's ok"

aaaaand…

[sudo] password for hodor: 

d’oh.

I checked the syntax in /etc/sudoers, and it was ok.

I checked whether any of the declarations that followed in /etc/sudoers could override the line I set for bran and hodor, none to be found.

Heck, I even put that line as the last line, so no line could override it. Nothing.

After a good hour of googling around and finding nothing, I remembered that the script is in a Git repository for which I just checked out a different branch. As it turned out, the script lost its executable bit.

So I set the executable bit again, as user hodor:

hodor@laketower:~$ chmod +x calm_down.sh
hodor@laketower:~$ logout
root@laketower:~# su - bran
bran@laketower:~$ sudo -u hodor /home/hodor/calm_down.sh "it's ok"
hodor.
bran@laketower:~$

it worked!

I’m sure there’s a legitimate security concern for this behavior, but dang! was this hard to figure out!

Change background color for content assist pop-ups in Eclipse on Ubuntu

The default grayish tone that is set for selection background in TreeViews on Ubuntu makes text unreadable on my display. Choosing an option among those proposed by Eclipse content assist menus turned into a leap of faith (it usually served me well so, yes, the first option should always be fine! :)).

After looking for an entry among the gazillion appearance-related menus in Eclipse I discovered that no, you can’t change the background color of selected items in TreeViews from within Eclipse. You must change it at system-level, don’t know why.. This StackOverflow question helped me a lot.

So, to change that light gray into a more friendly blue-ish (#55a3ba) without affecting every application in your system you can create a specific GTK theme in a gtkrc file.

Create a file named e.g. .gtkrc-eclipse somewhere (I put it inside my home folder) and write these lines inside it:

style "listitem" {
    base[ACTIVE] = "#55a3ba"
}

class "GtkTreeView" style "listitem"

Then you have to change your Eclipse launcher so that it loads your gtkrc file. To do so in Unity, I usually create a .desktop entry with alacarte (sudo apt-get install alacarte if you don’t have it in your system) and edit it with vim.

All launchers are stored by default inside ~/.local/share/applications, they’re a bunch of files whose names end in .desktop. What I do is launch alacarte (pressing Alt+F2 and typing alacarte), create a new entry in whatever category I find most suitable, set the executable name, path, icon and comment.

Then, I open the file created by alacarte with vim; alacarte creates its launchers in ~/.local/share/applications, they’re called alacarte-made-N.desktop: the most recent is the one you just created, of course, so just ls -ltr ~/.local/share/applications to find out which one is the one you want to edit.

Once I’ve found the correct file, I open it with vim to change the Exec line into this:

Exec=env GTK2_RC_FILES=/usr/share/themes/Ambiance/gtk-2.0/gtkrc:/home/myuser/.gtkrc-eclipse '/home/myuser/eclipse/eclipse'

(it’s all in one line!)

Please note that you can’t use ‘~’ as a placeholder for your home, you must write absolute paths as in /home/myuser/whatever. What you’re doing here is setting a theme for the application (defined in /usr/share/themes/Ambiance/gtk-2.0/gtkrc, but if you use another theme just change this path into the correct one) and overriding it with custom definitions taken from your gtkrc (:/home/myuser/.gtkrc-eclipse, this must be replaced with the actual path to your gtkrc file).

Save the file and change its name into something more mnemonic, like this: mv alacarte-made-XYZ.desktop eclipse.desktop.

Finally, open nautilus on that folder with nautilus ~/.local/share/applications/; drag the file you’ve just created and drop it to Unity’s bar.

Now you can finally enjoy content assist once again 🙂

Let users execute commands as other users without typing a password (sudo)

It’s been almost a year since I discovered the joys of SVN post-commit hooks (I started by following this excellent and concise guide), but I never really gave it the time it wanted: now that I have, my scripts finally work flawlessly and I’m very happy with the result!

One of the things I’ve done is to monitor only some specific folders in my SVN repository, folders that contain files that I want to copy to another folder that is monitored using inotify (I have a server Java application that inspects these files and decides whether they’re “accepted” to be served to clients.. I plan to switch to Java 7 to test the new java.nio.file package, but for now I use a little inotify bash script).

I needed a working copy of the SVN repository (well, just a branch actually), and I needed it to be updated whenever a file in one of the monitored folders is edited, added or deleted. So, I created a user called svnuser that just pulls updates whenever the post-commit hook tells it to. At first I thought of named pipes as a means to have the two processes communicate: a daemon script always running in background launched by svnuser waiting for notifications on a named pipe that are written by the post-commit hook; it seemed to work fine, but then I thought “wouldn’t it be easier if this script was launched by the post-commit hook itself?”.

It is 🙂

Post-commit hooks are executed by the user that is committing changes, so I had to use sudo. To configure sudo, type visudo (or, equivalently, vim /etc/sudoers as user root.. just remember to save the file using :wq! to override the read-only setting).

In the User privilege specification section you should see this line

root    ALL=(ALL) ALL

that means that user root can run any command (last ALL) on any host (first ALL) as any user (the ALL between parentheses).

You can add your definitions at the very bottom of the file (they’re executed in order, so you can override a definition with a more specific one just by putting the overriding definition after the overridden).
You can use groups, too! Just put a % symbol in front of the group name.
You can also apply a rule to a single command, or to a (comma-separated) list of commands by replacing the last ALL.
You can do a lot of stuff, actually, if you’re interested just dive into this page. I had to spend some time to figure out what I needed to do, so I hope that a little summary will help somebody.

I don’t want to force users to type their passwords every time that they commit some file to one of the “sensible” paths, so I included the NOPASSWD option.

Here’s the final line:

%svngroup ALL=(svnuser) NOPASSWD: /home/svnuser/svnsync *

that means that any user in the group named svngroup can run the /home/svnuser/svnsync script as user svnuser passing whatever parameter (last *) and without having to input their sudo password (NOPASSWD).

That’s it, now my post-commit hook just calls the svnsync like this:

sudo -u svnuser /home/svnuser/svnsync $UPDATED_PATH

Play the System Bell as shell commands end in Ubuntu/Debian

This is a nice little trick I started using after switching to Gnome3, as I don’t have the application switcher panel any longer: before, I could put my mouse cursor over that to see a preview of shell windows where a command is running.

Now I should keep moving the cursor to the top-left corner and wait for the animation to show all open windows, which is tedious when you don’t have a precise idea of how long will commands take.

So, the long hated system bell sound comes to rescue!

Just append ; echo -e "\a" after the command you want to run and… voilà, you’re in the event-driven world! 😛

Example:

wget http://www.kernel.org/pub/linux/kernel/v3.0/linux-3.2.13.tar.bz2; echo -e "\a"

This command of course won’t do anything if your volume is set to 0 or you explicitly disabled system audio notifications.

Change color scheme in Geany

After trying Sublime for a while, and quite liking it, I found myself in the middle of a deep customization of the editor… to make it work like Geany!

For quick editing of local bash/python scripts or configuration files there’s no editor that meets my taste better (I said local cause when dealing with remote files my all-time favorite is vim).

The one thing that I like more in Sublime than in Geany is its look: it’s very elegant, but in the end what I really missed in Geany was a dark editor theme.

I discovered this project on GitHub with several available themes, very easy to install (as in execute-install-script-with-no-options) but.. not that easy to choose from Geany’s interface!

[Update – Mar13] – unjordi posted a nice command line one-liner to get and install the geany-dark color schemes, here it is:

wget -qO- http://geany-dark-scheme.googlecode.com/files/geany_dark_filedefs_20100304_190847.tar.bz2 | tar jxv -C ~/.config/geany/filedefs/

After you’ve downloaded the color schemes and before editing the configuration file as described here below try to restart Geany and check if there’s an entry under View/Editor>Color Schemes>; if it’s there you can choose among all installed color schemes from a nice list! 🙂

If you’re out of luck (no list for you) you must edit Geany’s configuration file ~/.config/geany/geany.conf and find the color_scheme line. You must specify the whole file name of the color scheme you wish to use, without its path (it must be in the ~/.config/geany/colorschemes folder anyway).

So, to set your theme to tango-dark you shall have this line in your geany.conf file:

color_scheme=tango-dark.conf

Restart Geany and there you have your nice dark theme 🙂

[Update – Nov13] – a reader had troubles with the configuration file (always reverting to its original state, or not being read correctly by Geany), scroll down to November 5 2013 in the comments if you have the same issues!

Gnome3 (gnome-shell) is very slow using latest ATI Catalyst Drivers

Well, the 12.1 upgrade (Jan 25) at least made Gnome3 usable… The tearing and bad rendering seen with fglrx have finally gone but everything is painfully slooooooooooow.

Two things helped me get an almost responsive desktop, and I don’t know which one actually did the trick. They should actually do the same thing, but who knows?

The first thing I did is to go to the Catalyst Control Center and disable both Vsync (under 3D section) and Tear-Free (under Monitors) options. That seemed to give a little boost to the overall responsiveness of my desktop, but another thing I found out from a comment to a bug report on ATI’s bugzilla is to add this little magic line to your /etc/environment file:

export CLUTTER_VBLANK=none

This should be the equivalent for disabling the Vsync option from the Catalyst Control Center, I guess, but after rebooting everything seems to run a lot more smoothly!

Displaying a progress bar while using dd

[Update – June 2017] – as nvoss noted in the comments, as of coreutils version 8.24 (published 2 years ago), dd supports a nice status=progress option which does exactly what this post is about… At last! 🙂

dd is one tool I really love and one that really scares the hell out of me. It’s so powerful you have to show him respect, otherwise you’ll end up destroying all your precious data!
One thing it’s not very good at however is to show you some info on what’s going on and, most of all, how fast your files are being shredded to pieces never to come back again 🙂

So, say we’re using dd like this:

dd if=/path/to/input_file of=/path/to/output_file bs=4096

To get the usual

N record in
N record out
N bytes copied, M seconds, P transfer rate

we all learned to love, you can just

sudo killall -USR1 $DD_PID

from within another terminal and dd will display its statistics to the terminal you launched it from. Of course, you may add some

watch --interval=10 killall -USR1 $DD_PID

to update statistics at regular intervals.

But this is just boring.. What about some sort of progress bar? 😉

The trick is to break down dd in its input and output parts, and throw a pv in the middle, like this:

dd if=/path/to/input_file bs=4096 | pv -s SIZE_OF_INPUT_FILE | dd of=/path/to/output_file bs=4096

where SIZE_OF_INPUT_FILE is your best estimate of input_file size (M and G may of course be used for megabytes and gigabytes), and voilà, you get a progress bar that looks like wget‘s!

pv comes as a package for a lot of Linux distributions, so it should be no issue to (apt-)get it.

You may also have stat guess the file size for you, like it’s written here, but in case you’re dealing with /dev/sdX and such you’re out of luck, as stat will always tell your file is 0 bytes long.

SSH Tunneling with joy!

When dealing with several servers that don’t all see each other it is often a bit painful to jump from one SSH session to another, even more so if you have to type some password every time.
In case you are allowed to edit .ssh/authorized_keys (I don’t see a valid reason why you shouldn’t, but in the wonderful world of system administrators.. who knows?) your struggle is about to end. Provided, of course, that you use Linux 🙂

Let’s say you want to reach hostB (unreachable from your own host) by tunneling over hostA (which you have direct access to).

  1. Edit your .ssh/config file to include a stanza for each host; it should look like this:
    Host hostA
    User myUserNameForHostA
    HostName hostA.domain.com
    Port 22
    
    Host hostB
    User root
    HostName hostB.as.seen.from.hostA
    ForwardAgent yes
    Port 22
    ProxyCommand ssh hostA nc %h %p
    

    This will also let you type ssh h<TAB> having the shell auto-complete magic fill the remaining “ost” for you (the remaining A or B is up to you). Right now you may already tunnel over A to reach B, but still you would have to type in passwords for both host A and hostB every time you ssh hostB.

  2. Generate your id_rsa.pub in case you don’t have one, and add it to the authorized_keys list of both hostA and hostB:
    ssh-keygen -t rsa
    cat ~/.ssh/id_rsa.pub | ssh hostA 'cat >> .ssh/authorized_keys'
    cat ~/.ssh/id_rsa.pub | ssh hostB 'cat >> .ssh/authorized_keys'
    

And you’re done! Now you can ssh hostB without having to type any password!

In case hostA and/or hostB don’t have a .ssh folder, you should of course create it by executing

ssh hostA mkdir -p .ssh
ssh hostB mkdir -p .ssh

Nice thing is, you may also add a hostC that is accessible from hostB only by adding an entry to .ssh/config as you’ve done for hostB, carefully switching hostA with hostB and hostB with hostC!