I was doing a routine task – preparing a new CentOS server – today and ran into quite obscure problem.
I was at the point where I needed to configure VPN link but OpenVPN wouldn’t let me daemonize itself. It complained in the logs basically saying that the problem was this:
openvpn: daemon() failed: No such device (errno=19)
That’s weird. After an hour of troubleshooting this issue on the server I took it to #email@example.com where dazo, the channel operator, pointed out that some people previously had have a similarly looking problem, and that if /dev/null was involved it might be a similar or exactly that kind of problem.
I checked /dev/null with stat utility and it was indeed just a regular file. WHOA. This is a production server that doesn’t see software updates, tested and works for the most part as a clock. Utterly inexplicable at this point to me but I don’t have time to research this right now. I just wanted to make a post about it to remember to look into this later, because this is quite interesting and doesn’t happen very often. In fact, I’ve been working with Linux for at least 5 years now, and I’ve never seen anything of the sort. Not even my more than I am experienced colleagues.
There are many ways to do it depending on your context, i.e. whether you’re working with headless setup that doesn’t need to run X server – plain old console – or with an X-based setup.
In my particular case I had a CentOS box that ran without X server and experienced some obscure, intermittent lockups. So, I needed to hook up the display, hoping to see some output like kernel call trace or maybe some error messages the box locks up the next time. The problem was that the system would dim the screen and when the box locked up I couldn’t see anything that might had been printed on stdout.
After quite a prolonged session of error and trial, what I learned was that simply issuing setterm -blank 0 in a terminal over ssh session (didn’t try to directly enter this command, let me know if this works for you) wasn’t working. So, what I ended up doing was adding
% echo “/usr/bin/setterm -blank 0” >> /etc/rc.local
to the end of /etc/rc.local and rebooting the box.
That did it for me (finally! lol)
Here’s a very nice page that describes how to set up OSSEC active response e-mail notifications.
There’s one problem, though. In current OSSEC version 2.6 that configuration will leave you with AR rule, if once triggered, staying in loop forever. For example, if a common web attack is detected and you’ve configured OSSEC to respond with firewall drop AR, upon the timeout the offensive IP address will be deleted from the firewall configuration and re-added immediately after that. Thus, this cycle will continue endlessly.
I’ve wanted for a while to extract a radio station url for HBR1, Ambient from Banshee 2.0.1.
My first thought was to grep recursively and disregarding character case for ‘hbr’ in $HOME. That didn’t work.
After some time I realized that probably Banshee stored most of the data in a sqlite db. I was right about that, but finding the radio station url still wasn’t as simple.
Here’s what I did to get it printed out on my console:
~/.config/banshee-1 % sqlite3 banshee.db ‘select * from CoreTracks’ | grep -i hbr
3|2586|12|463|0|0||http://ubuntu.hbr1.com:19800/ambient.ogg||0|0|0|0|5|0|HBR1, Ambient|hbr1 ambient||, �
3|2587|12|464|0|0||http://ubuntu.hbr1.com:19800/tronic.ogg||0|0|0|0|5|1|HBR1, House|hbr1 house||, �
3|2588|12|465|0|0||http://ubuntu.hbr1.com:19800/trance.ogg||0|0|0|0|5|0|HBR1.com – I.D.M. Tranceponder|hbr1com – idm tranceponder||, �
Yeah, not pretty, but who cares as long as you can extract your data, right? Of course, if you’re going to re-use the output in your scripts you’ll have to figure out how to make the output prettier. If you do that, drop me a line in the comments section, please.