Leveraging screen to increase command-line multitasking

I am an avid fan of the Linux utility screen. It allows you to have multiple ‘screenlets’ inside of one command line session on a server, swapping between them as you wish. On top of that, if you get disconnected from your server because you have to do some admin work from a hotel room with a poor internet connection, the screen will keep whatever work you were doing on your server chugging along. If you need to fire up some long running process, but you don’t want to stay SSH’d into your remote server the entire time, screen will also let you ‘detach’ from it, leaving the command running, while you go off to Olive Garden to grab a bite to eat.

I’m not going to go into all the details of how to work screen… instead, I am going to cover what I use in 90% of my interactions with it, which is a surprisingly small list! First, we are going to get it all set up to give you a nicely configured screen session with a few screenlets in it. We can do this by placing a file called .screenrc inside of your home folder. Here are the contents of my .screenrc:

shelltitle ''
vbell on
autodetach on
startup_message off
defscrollback 2048
termcapinfo xterm* ti@:te@

hardstatus alwayslastline "%-Lw%{= BW}%50>%n%f* %t%{-}%+Lw%< %=%D %M %d %c" hardstatus string '%{= kK}%-Lw%{= KW}%50>%n%f %t%{= kK}%+Lw%< %{=kG}%-= %d%M %c:%s%{-}'

screen -t r00t 0 bash
screen -t vimTerm 1 bash
screen -t general 2 bash

I can’t take complete credit for that .screenrc. The hardstatus line I pulled off the internet somewhere ;)

It works out really well, it gives a nice bar at the bottom which shows all of your screenlets and highlights whichever one you are now on. It also keeps a clock in the bottom right corner, and will flash the title of a screenlet if a ‘bell’ go’s off in it.

Now that we have a good screenrc, you can fire up screen by running the command ‘screen’ (you may need to install screen from your distributions repository). But we can take this one step further and have your system fire up screen automatically when you SSH into the server by adding a little snippet of code at the end of your .bashrc:

if [ $SSH_TTY ] && [ ! $WINDOW ]; then
  SCREENLIST=`screen -ls | grep 'Attached'`
  if [ $? -eq "0" ]; then
    echo -e "Screen is already running and attached:\n ${SCREENLIST}"
    screen -U -R

That will fire up a screen session when you SSH in unless someone is already attached to your user accounts screen session. Now that we have screen configured, and we have your server starting it up automatically when you log in, lets learn how to use it!

If you are using the .screenrc that I provided above, you will notice the 3 screenlet’s titles at the bottom (r00t, vimTerm and general). You can adjust those names by editing the .screenrc. In order to swap between different screenlets use the keystrokes Ctrl+a NUMBER. The number will be whatever number of screenlet you want to go to, so if you want to go to screenlet 1, it would be ‘Ctrl+a 1′.

If you want to detach from your screen, leaving everything running, and enabling you to disconnect from the server, use the keystrokes Ctrl+a d.

If you log into the server and you get a message saying that ‘Screen is already running and attached’ you can detach screen from the other location and attach it to you current SSH session with the command ‘screen -D -RR’. That command will do whatever is necessary to get you a screen session… detaching other sessions and attaching, starting a new session, attaching to a detached session etc.

By cryptk on August 22, 2012 | Uncategorized | A comment?

Basic ubuntu server security

So this blog post is going to cover some basic security do’s and don’ts.  The end goal will be to have an Ubuntu powered server that is not only decently secure, but also not so secure that it is a pain to work with.  I will be covering many things that should be done as part of basic security, some general best practices, and I will also hit on one thing that I find to be a HUGE annoyance than many many… many… people do, thinking that it will make their server more secure, when in reality it does next to nothing.  I will be targeting an Ubuntu 11.10 server in this article, but everything that I have in here should work on anything 10.04 LTS and up.  I am mainly going to be focusing on securing SSH logins. Read on after the break

Click to continue reading “Basic ubuntu server security”

Installing a mail server (Part 1 of 2)

This will be a two part post, the first part will cover setting up a mail server to act as a local relay (or even relaying mail through an external server). This is useful for adding to a LAMP server (what a LAMP server is, and how to set one up is covered HERE).  By the end of the first part, you will have a fully functional mail server which can be used for things like sending emails for user account password resets, new account creations, post notifications etc… This is a piece that you will likely need if you are running a website based on a framework such as WordPress, Joomla, PHPbb or one of many others.  You will likely also need one if you are coding your own website from scratch as well.

This walkthrough will be targeted towards Ubuntu 10.04 LTS and my goal is to cover all of the basics to have your mail server be secure, and have some virus and spam protection.  Later I will write the second portion which will turn your secure local mail relay into a full mail server with incoming and outgoing mail, mailboxes for users, etc.

It’s pretty long, so catch the link below to read it all.

Click to continue reading “Installing a mail server (Part 1 of 2)”

Setting up a git server with xinetd, gitolite and cgit (the right way)

So I need to set up a git server for one of the projects that I work with, so I figured I would document how to do it properly. Even though I am a huge fan of the web server nginx, this server in particular is already set up with apache2 so I will be serving cgit through apache2. Perhaps later I will add in an nginx config for cgit.

I am using a resh install of Ubuntu 10.04 LTS with all updates applies for my testbed while I write this, but the instructions should apply equally well to all versions of Ubuntu up to at least 11.10 (when it releases) and likely versions afterwards as well.

As usual, this is going to be a long one, so catch the rest after the linkeration..

Click to continue reading “Setting up a git server with xinetd, gitolite and cgit (the right way)”

Running WordPress with nginx, php-fpm, apc and varnish

Recently I built a server to host the blogs and other PHP powered websites of a few family members.  I wanted something lightweight, efficient and fast.  With that in mind I threw out the “standard” of Apache and it’s mod_php and instead went with something else entirely.  This article is going to be geared at people running a server with Ubuntu 10.10 or newer (sorry LTS fans… php5-fpm isn’t available in your repos… but you can backport it fairly easily).  I’m going to be including some config file examples as well, everything you need to get this up and running will be included… and it’s easier than you think ;)   Catch the details after the break

Click to continue reading “Running WordPress with nginx, php-fpm, apc and varnish”

How to make a LAMP server

The majority of this information is for Ubuntu, but if you are running something Red Hat based, such as CentOS, then at the bottom there is a nice command for you.

So I was asked a question the other day… “How do I install LAMP on my linux server?”. First, let me cover a few things about a LAMP server. LAMP is not a piece of software itself, it is a term used to describe a particular server configuration. It stands for Linux Apache MySQL PHP (get it… L-A-M-P). So you don’t install LAMP, you install the software I mentioned earlier (and a few extra pieces to tie them together) and you have what is called a LAMP server.

A LAMP server is pretty much your “cookie cutter” web server. It has PHP for server side web code processing, it has Apache for serving that content, and it has MySQL as a database for storing… uhm… data.

I am not going to cover how to install Linux, there is already some great documentation (like THIS ONE for Ubuntu 10.10 server edition, or if you are an LTS fan THIS ONE for Ubuntu 10.04 LTS).

Installing a LAMP server in Ubuntu is amazingly simple. There is even a TUI (Textual User Interface… think of it as command line graphics with nice colors and such) to make it so simple a caveman can do it. After you have your Ubuntu powered server up and running, log into it. Once logged in, run the following command:

sudo tasksel

This will bring up the tasksel TUI. Next use the up and down arrows to highlight the box next to ‘LAMP server’ and press the spacebar to select it. You should now have an *asterisk* next to it. Then press TAB to highlight the OK button and press enter. Your server will start cranking away turning itself into a full fledged LAMP server. If you don’t see the option for ‘LAMP server’ (which could be the case if this is a brand new installation) then try exiting tasksel, running an `apt-get update` and then going back into tasksel. It will ask you one question as it go’s…

Password for the MySQL root user: This is a prompt asking you what you would like your MySQL root user to have. This is not the same “root” as your root user account, but it serves a similar purpose. This will be the password used to log into the database with full administrative permissions, able to create and delete anything from any database. Definitely make this a strong password and do not share it with anyone that doesn’t absolutely need it. It will ask you for it twice to make sure that you don’t have any typo’s in it.

That’s it… your done… no really… that’s all there is to it… You can now host your own PHP website (perhaps even your own wordpress blog).

Do note that you can have a LAMP server running on any flavor of Linux, but since I am an Ubuntu administrator, and I prefer Ubuntu, I tend to give instructions for ubuntu. Red Hat based distributions have a similar function called groupinstall which you can use by running the command:

sudo yum groupinstall "Web Server"

And if you are on a BattleToads server the command would be:

kindlydotheneedful LAMP
By cryptk on August 16, 2011 | Uncategorized | A comment?

Enabling automatic updates on Ubuntu

So, to start I am glad that I have received a few requests for topics.  One of them kind of covered two topics, automatic updates and log file management.  I am going to split them up into two different posts, with the first being automatic updates.

Ubuntu, and many other distros, have it built in to enable automatic updates through their package managers.  While you can install updates manually through the command line in Ubuntu through apt-get or aptitude (I prefer aptitude), sometimes you have a system that you want things a little more “hands free”.  In Ubuntu (and other Debian/Debian based distros) this is provided by the unattended-upgrades package, available in your repository.  On the desktop release, it is already installed, on the server release it is not.

First, it would be bad of me to not point out the official documentation on this.  It is targeted at the server, but it applies to the desktop as well: https://help.ubuntu.com/10.10/serverguide/C/automatic-updates.html Note that is for Ubuntu 10.10, but they have similar documentation for other releases as well.

In Ubuntu 10.10 (and 11.04 natty), it is set by default for Security updates only, but it is also only set to update the package list.  The unattended-upgrades package gives quite a bit of control over what it will and will not do, as well as options for letting you know what it did.  In order to get it to actually install the packages automatically, you would need to edit the file /etc/apt/apt.conf.d/10periodic .  In this file you will find a few options, as mentioned, by default the first one is enabled, updating the list of available packages.  All of the settings in this file are how often that task will be performed in days.  Note that this file is part of the package update-notifier-common which is not installed by default on the server release, but you can create it easily.  The default contents of this file are:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "0";
APT::Periodic::AutocleanInterval "0";

Or you can install the update-notifier-common package which comes with some other nice goodies as well such as adding some information to your login MOTD if there are updates available, a reboot is required for a package update, and a few other nice things to have.

You can set it to download the new updates (but not install them) with the second option, as mentioned, setting it to 1 would have it do that every day, once per day, 3 would be every 3 days.  The third option is how often you would like it to remove un-installed packages from the local package download cache.  One option that may not be in that file by default (but you can add it) is the option to actually make it install the updated packages.  If you set APT::Periodic::Unattended-Upgrade to a value, then new packages will be installed that often.

Now that we have covered how to make it install upgrades automatically, what if you would like to be notified that it happened?  You can always check /var/log/unattended-upgrades, but that go’s against my first rule… I feel that whenever possible, my servers should come to me, not the other way around.  So now we will make unattended-upgrades let me know when it does something.  For that, we go to the file /etc/apt/apt.conf.d/50unattended-upgrades .

In this file, there is a setting Unattended-Upgrade::Mail, if you un-comment this line, and set it to your email address, your system will email you a summary of packages installed, or any errors encountered.  Please note that for this to work, you will need something that provides /usr/bin/mail.  The package mailx will provide this, it will also work with sendmail, postfix and others.  Do note that because there will be several URL’s, all plain text, and the from address will be root@hostname, that the email will likely be spam filtered (it is for sure by gmail).  After the first email arrives, just check your spam folder and then whitelist the sender of the email.

Also, the default is for unattended-upgrades to only work with security related updates.  This is also modified in the file /etc/apt/apt.conf.d/50unattended-upgrades .  If you would like it to also install updates from sources other than just the security repository, at the very top of this file you will see the entries for the other default repositories.  Any that you un-comment will also get some unattended-upgrade love.  There is also a setting in there to have it automatically reboot the server if a package install requires it… I prefer to leave this one off as I like to be in control of any downtime that my server has.

This pretty much covers how to get off the ground with unattended-upgrades.  If you have any questions about it, or if you want to know if it can do something in particular, leave a comment!

Things to consider when hosting a website

Doing what I do for a living, I tend to see the same mistakes made over and over.  Luckily where I work I am in a position to have a conversation with the person that made the mistakes, offer up a little bit of education, and most times they are very receptive to it.  I am also in a position where I can help them to transition from their currently slow and possibly buggy solution to something that gives them the speed and performance that they want.  This entire post is going to be targeted at Linux powered servers but many of the points will apply equally as well to Windows powered servers.

This one is a little bit long so if you want the full disk, click the link

Click to continue reading “Things to consider when hosting a website”

Mentoring SysAdmins for FOSS

Find your Luke!

The population of SysAdmins for FOSS projects, which was never large, is rapidly graying. We need you and your friends to become SysAdmin Yodas.  We need you to be the mentors and trainers of the next generation of admins. It isn’t enough to merely know how to do things, and to do them, you need to pass on what you know.

The rise of the massive FOSS hosting sites like GitHub, SourceForge and Google Code have given many sites a chance because the hosting “just works.” But projects like distributions and OS developments and project with multiple, intersecting goals and timelines require resources that SourceForge and others just can’t supply:  custom builders, redmine, trac, bugzilla, mediawiki all require substantial help from sysadmins, and hosting.

Some projects are lucky enough to get hosting from places like OSU OSL , but most projects are not so lucky.

We need a methodology, a path to bring in new bright people who can do those things for our projects, both to get some of the painful load off of us, and to prepare for the future when we may not be here.

Future posts on this site will address recruiting, mentoring practices, training processes, and so forth.  This site will not be a “how to set up a copy of mediawiki” site.  This isn’t about how to do any particular job, but rather, how SysAdmins learn how to do -any- job.  None of us are only ever asked to do stuff we already know.

How do you train someone to address a task they’ve never seen before?  What sorts of attitude, philosophy and problem solving methods should be used?  How do you teach someone how to avoid applying a patch for version 1.3 to an install of version 7.2?  How to teach that google is your friend, but it’s a friend who has the potential to give you very bad advice?

Much of the discussion here will focus on that kind of subject: attitude, problem solving and philosophy.

We strongly encourage your participation.  Please feel free to comment and complain and participate in conversations as we attempt to define best practices for the community.

P.S. Why is Ada Lovelace up there, besides being a pretty picture of a girl?  Because she embodies a part of the philosophy we’re thinking about.  Ada Lovelace is not the sort of person ANYONE would have thought of to be a programmer, but she was given an opportunity and ran with it and, she documented and shared her work so that future generations could build on what she did.  She’s both the symbol of “don’t reject a Luke just because they seem unlikely” and “you haven’t finished until you’ve written it down.”  –  More on both of these in future discussions.

By admin on January 24, 2011 | Uncategorized | A comment?
WordPress Loves AJAX