Linux Blog

AutoSSH

Filed under: Linux Software,Quick Linux Tutorials — TheLinuxBlog.com at 9:15 am on Friday, December 14, 2012

I’ve written in the past about automatically performing an action when a host comes back online. However, this post is geared towards a more permanent solution than the one time usage connection.

Introducing autossh:

Description-en: Automatically restart SSH sessions and tunnels
autossh is a program to start an instance of ssh and monitor it, restarting it
as necessary should it die or stop passing traffic. The idea is from rstunnel
(Reliable SSH Tunnel), but implemented in C. Connection monitoring is done
using a loop of port forwardings. It backs off on the rate of connection
attempts when experiencing rapid failures such as connection refused.

It is available on most distributions, and even jailbroken iPhones. Its a great utility.

If you want to use it here’s howto:

Install it:

:~$ sudo apt-get install autossh

Run it:

:~$ autossh [host]

That’s pretty much all there is to running it, although if you want to check out all of its features you should read the help file and man pages. If you want you can resume your SSH sessions without using a password, by using the no password SSH login technique.

Bash Script Renaming Files

Filed under: Shell Script Sundays — TheLinuxBlog.com at 3:15 am on Sunday, February 6, 2011

I recently needed to rename a bunch of files. I didn’t want to do it manually because it would take too long and I don’t like copying+pasting that many times. This is where shell-scripting comes in handy. (Read on …)

A Manpage Template for your Scripts

Filed under: Shell Script Sundays — TheLinuxBlog.com at 11:44 am on Sunday, June 21, 2009

So, you just finished that killer script and the first thing you want to do is write that man page for it right? Not exactly? What do you mean?
Writing a man page isn’t that hard and will give your users an idea of how to use a script.

Here is a basic template for creating your own man pages:

.\" This is a comment
.\" Contact Owen@thelinuxblog.com
.TH man 1 "21 June 2009" ".1" "Man Page Example"
.SH NAME
Man \- Example Man Page
.SH SYNOPSIS
Example Man Page
.SH DESCRIPTION
This is an example of a man page.
.SH OPTIONS
No options for this man page
.SH SEE ALSO
man(1), groff(1), man.config(5)
.SH BUGS
No known bugs for this template, except you might want to replace the quotes if you copy from my blog.
.SH AUTHOR
Owen (owen@thelinuxblog.com)

When you’re done with the gruelling task of writing documentation (which your users won’t read or thank you for) just plop it the correct man section in /usr/share/man
That’s all there is to it!

Run Levels in a Nutshell

Filed under: Quick Linux Tutorials — TheLinuxBlog.com at 9:03 am on Wednesday, March 11, 2009

Run levels in Linux are a great thing. Basically, a run level is by definition a configuration for a group of processes. The run levels and default run level is specified in /etc/inittab. Most Linux systems these days, with exception of a few boot into run level 5 which is generally a graphical user interface such as KDM or GDM. The others boot into run level 3 most servers will boot into this run level which is multi-user with networking but no X, and is many users preference.

To define what run level your system boots into by default you would edit the /etc/inittab file and edit the line similar to:

 id:5:initdefault:

This is run level 5, if you wanted to switch to command line you’d change the 5 to 3 and vice versa.

If your not ready to make the jump yet but would like to check it out, you can (as root) use the command telinit to tell init to change run level. If you are in run level 5, try (be prepared to lose everything in X, as it will kill everything for you)

 telinit 3

If you are doing maintenance, you may want to switch to level 1 which is single user mode. Level 2 on Fedora is the same as 3 except it doesn’t have NFS support.

Level 0 is halt and run level 6 is reboot which are the best ones to accidentally set as a default run level (trust me on this one.) For more information on the different run levels check out the man pages.

Timing your reboots with Twitter support!

Filed under: Shell Script Sundays — TheLinuxBlog.com at 12:01 am on Sunday, July 20, 2008

Firstly, I’d like to start off by saying that all of the concepts in this post should have been covered in other posts, so I will not go into great detail on the specifics of this script. If you need to know more information about any of the commands, check the man page section at the bottom of this page, from the man pages will be examples of other posts covering similar topics.

The purpose of this script for me was to time my reboot times. It could be modified to log the time it takes to replace hardware or add memory, but thats another post. Since we are logging reboot times, we are (hopefully) dealing with small numbers and therefore don’t have to deal with formatting time (at least not for now.)

The script should work on multiple systems that have bash. There is nothing too special about it. It uses the reboot command so the user this is launched as will have to have access to that command. You put the script in the users bin directory and chmod it. The user must also have write access to this. Also, they must have write access to their home directory, but this should not be a problem for most. Line 8 of the script needs to be changed to the user you plan on running this as.

After that test that the timereboot command works by typing timereboot:

[owen@linuxblog ~]$ timereboot
Usage: /home/linuxblog/bin/timereboot {time|ttime|back}

Once that is done, thats a pretty good indication that the script is working. Next, I suggest commenting out the reboot command on line #25 if this is a critical mission and you don’t want to reboot multiple times to get it working. If not go ahead and try the time command. Once your system is back up and your logged in you type the “timereboot back” command, it will then tell you the time taken since your system was done.

Once you have verified that the time works, you can go ahead and add it to your bashrc to automatically perform the action once your logged in. All you need to do is add a line like this:

home/linuxblog/bin/timereboot back

Now, if you want you can try again and see the results automatically.

“Thats great, but how do I post it to twitter?”

Well, there is one last thing that you have to do to get your reboot time posted to twitter. Edit line 55 and change to your twitter username and password. Do the same thing as before to reboot, but use the ttime parameter to log to twitter.

This script, does not post to twitter that you are rebooting (although it could) nor does it format the time, but it works and should give you a starting point if you are interested in doing this. It doesn’t really serve a real purpose other than to inform people how quickly or how slow you reboot. Also, please note that this is not a start up time. This times from when you issue the command until you issue the back command, or log in using the .bashrc method.

If you have any questions about this script or any other idea’s let me know and I’ll be happy to help or implement them for fun.

And here is the Twitter reboot script

The Linux Blog – More May Updates

Filed under: The Linux Blog News — TheLinuxBlog.com at 6:30 am on Monday, May 26, 2008

If you read my last Linux Blog update post you will have noticed that I added links to the man pages that have examples of how to use that command. This blog post is to tell you that I have implemented that feature but the reverse. In other words, when ever you view a Linux Blog post that I have written you will see links to the man pages of the commands used in that post and from there you can navigate to other examples of how to use that command. I hope that this feature is a useful one for The Linux Blog readers, if it is let me know and if it isn’t tell me you like it any way. I’m going to be adding more man pages soon since I have found that not all man pages that I have are on The Linux Blog. I will also be adding more man page sections for the ones I missed out.

Now that I have implemented that function the only thing I really have to do is have the ability to add, update and manage man pages on the fly.

More news
I have also been corresponding with the guys over at Wakoopa about working on a client to their web application for Linux. I will let you know more information as it becomes available. I am very interested in writing a client for their service and would love for Linux users to be able to join in on the fun!

Thats all for now,

- Owen