sudo everything as anyone without a password prompt

problem: you can sudo as root without a password but not other users

You want to be able to sudo from any host, as any user (and/or group), any command, without being prompted for your password. Right now you don't get the pw prompt for root, but you do get prompted for other users (and/or groups).

This is in part, due to the most commonly known and distributed NOPASSWD sudoers cfg. Its easy to tweak it to give you NOPASSWD for _EVERYTHING_. I personally find the sudoers config and man very hard to follow. What about you? It was only through looking at other cfg's online and trial and error, that I was able to figure out the right syntax.

solution: update sudoers cfg

Its easy when you know how! Right?

#user    host    (user:group)    tag         cmd
kyle     ALL=    (ALL:ALL)       NOPASSWD:   ALL

In English "On any host, as any user or group, allow kyle to run any command without a password". I hope this proves useful again one day!

Are you loosing your angle brackets? - php and libxml2

problem: php processes some xml and your angle brackets in said xml vanish!

TLDR: use the CDATA tag to wrap your character data to avoid having angle brackets vanish.

I encountered this bug for the first time when I was importing a Cacti xml graph template via the Cacti web UI. On the surface everything seems to go well with the import process but then nothing was graphing and looking deeper, it was clear the config for the graph(s) was broken, due to missing < > angle brackets.
The brackets we're correctly encoded in the xml, it seems that somewhere between php and certain version of libxml the encoded angle brackets get stripped out.

Online there are a few bug reports but no single central bug id that I could find on this. One of the more useful shares online was a bug detail report for a closed google code project which provides Cacti mysql templates. Here is the bug detail, very useful info from Elan there.

During my search for solutions, it seemed likely that a bug was regressed or introduced in libxml, but that isn't certain. It would seem that the latest stable php 4.2 on Debian squeeze and libxml2 (as of writing 2.7.8.dfsg-2+squeeze3) still has the bug.

There is also some useful info on a bug report for MediaWiki project, entitled: Import strips angle brackets on some installations (libxml2 entity bug). To summarise, the consensus seems to be that its an upstream but with libxml2. The evidence I have found would agree with this.

Currently my systems are pinned on PHP 4.2 packages, perhaps this bug is not a factor in non pinned Debian squeeze systems?

impact: wastes time - fixing things that shouldn't really be broken.

solution: use the XML CDATA tag

I can provide is a way of easily checking if your set up has the bug or not. Props to Elan for this.

$ php -r '$p = xml_parser_create(); xml_parse_into_struct($p, "<path_php_binary>", $vals, $index); print_r($vals);'

A system suffering from the bug will include the output:

[value] => path_php_binary

A system NOT suffering from the bug will output:

[value] => <path_php_binary>

Now add the CDATA tag and see if the bug goes away? You don't even need to use entities when using the CDATA tag.

$ php -r '$p = xml_parser_create(); xml_parse_into_struct($p, "<![CDATA[<path_php_binary>]]>", $vals, $index); print_r($vals);'

citation:

Props to:
Elan Ruusamae for their bug detail report on the mysql cacti templates project.

testing for interactivity in a bash script

problem: you want to know if your bash script is being run interactively or not

This can be very useful to know, for example, if you want to programmatically determine if you should output to stdout, OR only to a log file because your script is running non-interactively.

When a script is running interactively, it means a stdout is present and one can output things to stdout and the user will see them.

When a script is running non-interactively, for example when cron runs a script, stdout does not exist.

solution: check if stdout is a tty

As with so many things, there is more than one solution, but this one seems to be rock solid and very portable.

is_interactive() { if [ -t 1 ]; then return 0; else return 1; fi }

As The Advanced Bash-Scripting Guide points out, for a complete test, one needs to check if stdout could be a socket too. Here is is the improved check:

is_interactive() { if [[ -t 1 || -p /dev/stdout ]]; then return 0; else return 1; fi }

I hope you enjoy and have fun tuning to your needs.
FYI. I tested the functions with cron and ssh on Debian squeeze (6.0.4) and bash 4.1.5.

citation:

Props to:
The Advanced Bash-Scripting Guide

How do I ask screen to behave like a standard shell?

I have found myself asking this question a few times, but never really got motivated to find a solid answer until recently.

I stole the question title from a good thread over at serverfault. Where I also contributed my findings.

I hope this share helps someone!

citation:

Props to:
rg3 @ LinuxQuestions.org for this share.