Ubuntu Lucid Setup - Part 2

Now that we've secured access to our Ubuntu Lucid slice we can update it and get it ready for the rest of the server install.


OS check

First thing is to confirm what OS we're using. We know we should be using Ubuntu Lucid but let's see:

cat /etc/lsb-release

You should get an output similar to this:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.04
DISTRIB_CODENAME=lucid
DISTRIB_DESCRIPTION="Ubuntu 10.04 LTS"

Good.

Using free

Memory usage should be very low at this point but let's check using 'free -m' (the -m suffix displays the result in MB's which I find easier to read):

free -m

It's nice to know what is going on so let's look at that output:

.                  total       used       free     shared    buffers     cached
Mem:           254        55          199          0           2               21
-/+ buffers/cache:      30          223
Swap:            511        0           511

The line to take notice of is the second one as the first line includes cached memory - in this demo slice I have 254MB memory in total with 30MB actually used, 223MB free and no swap used. Nice.

.bashrc

Normally the "ls" command doesn't list files that start with a period. Those are usually configuration files or directories, and ls hides them so they don't clutter up your directory view. To see all of what's there, run:

ls -a ~

The "-a" option is what tells ls to list all files, not just the non-configuration files.

You'll see several files, but let's focus on ".bashrc" right now. This is ultimately where your user environment (the "shell") will look for its settings. Go ahead and open it for editing:

nano ~/.bashrc

Inside you'll see a lot of shell script commands — don't worry if you don't understand it all. Anything we add at the end of the file will override what came before. If you want to, say, change your prompt, you don't necessarily need to figure out what all the "if" statements in there by default are for, and which line you need to edit. You can just add your own setting at the end.

Custom prompt

With that in mind, let's look at how to change your prompt. At its simplest, the prompt's format is set with the "PS1" environment variable. It consists of some numbers that determine color and some codes that act as stand-ins for variables like the current working directory and your hostname. To set your prompt to just your hostname and working directory, both in different colors, you could add this line to the end of the .bashrc file:

PS1='\[\033[0;35m\]\h\[\033[0;33m\] \w\[\033[00m\]: '

The chunks like "0;35m" and "0;33m" are what control the colors - those are pink and brown, for example. Other colors you can substitute include "0;32m" for green and "0;36m" for blue — it's just a matter of changing those numbers.

Other important parts of that jumbled collection of characters are "\h" and "\w", which represent the hostname and working directory, respectively. If you wanted to include your username in the prompt you could add the "\u" code along with an "@" symbol, and it would look like this:

PS1='\[\033[0;35m\]\u@\h\[\033[0;33m\] \w\[\033[00m\]: '

Before we see what that will look like, however, let's also look at another useful feature of your shell, aliases.

Alias

The "alias" keyword lets you set a shortcut for another command. Some examples to get you started, which can be added to the end of your .bashrc file:

alias free="free -m"
alias update="sudo aptitude update"
alias install="sudo aptitude install"
alias upgrade="sudo aptitude safe-upgrade"
alias remove="sudo aptitude remove"

They're pretty simple examples, and are just meant to save you a little typing. Notice that you can essentially replace a command with an alias, like we did by setting the alias "free" to be a shortcut for "free -m". With that alias set, when you type "free" on the command line, behind the scenes the shell actually runs "free -m", so you don't have to type the extra characters to get the memory usage numbers in megabytes.

Similarly, those other aliases are shorthand for some aptitude commands to update or install packages. Since "sudo" is run behind the scenes you'll still have to type your password, but at least before that you won't have to type as much to run an update or install a package.

To activate the changes you've made to the .bashrc file, either log out and log back in or enter this command:

source ~/.bashrc

If you set a value for "PS1" above, you'll see your prompt change. Feel free to go back and change the colors or format of the prompt, or add your own aliases.

Set locale

You can check the current locale setting for your slice by running:

/usr/bin/locale

If the code doesn't match what it should be for the localization you would like to use for your slice (or if it uses a generic locale like 'POSIX'), run something like the following commands:

sudo /usr/sbin/locale-gen en_US.UTF-8
sudo /usr/sbin/update-locale LANG=en_US.UTF-8

'Something like' because you may want to use a locale other than US English. If so, substitute the language code for 'en' and the region code for 'US' above. The locale 'cy_GB.UTF-8' would designate Welsh for the language and Great Britain for the region, for example. A complete list of language and region codes can be found here.

If you change the default locale for your slice you will need to log out and log back in to see the change when running 'locale' by itself again.

Package repositories

An Ubuntu Slice comes with a basic set of repositories.

Have a look at the enabled repositories by running:

sudo nano /etc/apt/sources.list

You should see something very much like:

deb http://archive.ubuntu.com/ubuntu/ lucid main restricted universe
deb-src http://archive.ubuntu.com/ubuntu/ lucid main restricted universe

deb http://archive.ubuntu.com/ubuntu/ lucid-updates main restricted universe
deb-src http://archive.ubuntu.com/ubuntu/ lucid-updates main restricted universe

deb http://security.ubuntu.com/ubuntu lucid-security main restricted universe
deb-src http://security.ubuntu.com/ubuntu lucid-security main restricted universe

Each line specifies either a binary package repository ('deb') or a source package repository ('deb-src').

You can, of course, add more repositories whenever you want to but I would just give a word of caution: Some of the available repositories are not officially supported and may not receive any security updates should a flaw be discovered.

Keep in mind it is a server we are building and security and stability are paramount.

Update

Now we can update the package list that aptitude uses.

sudo aptitude update

NOTE: If you have used the .bashrc aliases shown above you just need to enter 'update' as the alias will use the entire command. I've put the whole thing here so you know what is happening.

Now we have set the locale and updated the sources.list repositories, let's see if there are any upgraded packages available:

sudo aptitude safe-upgrade

As with all installs have a careful look at the list and, once happy, press 'y' to continue.

That's really the basics done for the Slice.

Once any updates have been installed, we can move on to installing some essential packages.

Development Tools

Ubuntu has some handy meta-packages that include sets of pre-defined programs required for a single purpose.

So instead of installing a dozen different package names, you can install just one meta-package. One such package is called 'build-essential'. Issue the command:

sudo aptitude install build-essential

Notice the programs that are to be installed include gcc, make, patch and so on. All these are needed for many other programs to install properly. A neat system indeed.

Enter 'y' and install them.

You might get a message like this in aptitude's response when you go to install the development tools:

The following packages are BROKEN:
  libc6-i686

It's less of a problem than it sounds like, fortunately. It doesn't actually mean your system is broken, it just means aptitude did some checking on files and versions and decided something didn't add up.

If you do get that warning aptitude will also suggest a plan that will correct the offending package. Say yes to that, and then you can say yes to the actual installation. When aptitude installs the build tools it will also update the libc6 package it complained about, fixing the issue.

Now we have the necessary packages should we want to build an application from source.

Done

The console is now informative and less drab, locales have been configured and basic compile tools have been installed. Quite a lot happening here but now we have a more secured Slice with updated packages ready for the meat of the server to be put in place.

  • -- Jered

Article Comments:

Oskar Kornecki commented Fri May 07 09:36:01 UTC 2010:

You'll actually find that in Ubuntu 10.04 the bash profile is actually at

~/.profile not ~/.bash_profile

Jered commented Fri May 07 14:48:09 UTC 2010:

The bash shell will check for either file in a user's home directory (on any distribution). The .bash_profile takes precedence over an existing .profile. We use that file in the setup article for the sake of ease and consistency. Well, that, and because that way the prompt setting and anything else added will apply only to the bash shell, and won't cause anything wonky to happen if you try another shell that parses .profile (like ksh or zsh).

Oskar Kornecki commented Fri May 07 15:34:36 UTC 2010:

Ah, makes sense! Thanks for the explanation, learnt something new :)

Peter commented Tue May 18 14:36:28 UTC 2010:

nitpick:

We know we should be using Ubuntu Karmic but ....

should be

We know we should be using Ubuntu Lucid but ...

Jered commented Wed May 19 01:30:21 UTC 2010:

Darnit. Fixed. Thanks for pointing that out.

Greg commented Thu May 27 00:46:25 UTC 2010:

I'm running the locale settings (defaulting en_US) like suggested.

I've generated, installed, logged out, and they aren't updating for some reason. They all show "POSIX" for some reason.

Is there anything else missing?

Jered commented Thu May 27 16:10:27 UTC 2010:

Hm, that should be all there is to it, really. Run the two commands there to generate the locale and then set it as the default. Then you'd want to log out entirely from the slice and when you log back in...Well, in theory, typing "locale" would then show the new one. You are running the update-locale command with sudo, right? And it doesn't return any errors?

Andy commented Fri May 28 05:07:20 UTC 2010:

I'm having the same problems switching the locale. I'm changing it to en_AU, but it's still showing "POSIX"

Jered commented Fri May 28 16:15:55 UTC 2010:

I'm honestly not sure what could be causing the problem, since I'm unable to replicate it. If any of you do find a cause, definitely let me know.

In the meantime, though, the files to look at for troubleshooting this are "/var/lib/locales/supported.d/local" (which should hold a list of generated locales and should have been added to by the locale-gen command), as well as "/etc/default/locale" (which should list the default locale you want, and should be set by update-locale).

Once you make sure the locale you want is on the list of locales, run "sudo dpkg-reconfigure locales" and then try running the update-locale command again. If the desired locale is in the /etc/default/locale file, then it's possible the default locale is being overridden by a setting in your .bash_profile or .profile. Try adding a "LANG=en_AU.UTF-8" or the like to your .bash_profile to see if that will at least set the locale for the user you edit (after logging out and logging back in again, of course). One final possibility to try would be to use "ISO-8859-1" instead of "UTF-8", in case there's a problem with the UTF-8 version of that generated locale.

Tom commented Fri May 28 23:06:55 UTC 2010:

I also have the locale problem. Logging in and logging out does not fix the POSIX issue.

Rodrigo commented Sat May 29 08:50:38 UTC 2010:

Jered, a couple things:

  1. Can you explain why to use .bashprofile instead of .bashrc? There was no .bashprofile in my home, so I created a new one.. Seems that the addition of .bash_profile makes the stuff in .bashrc to not take any effect though. I guess I can easily fix this by passing the stuff from .bashprofile into the end of .bashrc. But I'd like to better understand the rationale behind .bashrc, .bashprofile, and .profile for that matter.

  2. I also have the POSIX locale problem. Here's some more debugging info: Running 'sudo locale-gen en_US.UTF-8' more than once yields:

Generating locales... en_US.UTF-8... up-to-date Generation complete.

And 'sudo /usr/sbin/update-locale LANG=en_US.UTF-8' runs without errors, but also without any output.

$ cat /var/lib/locales/supported.d/local en_US ISO-8859-1 en_US.UTF-8 UTF-8

$ cat /etc/default/locale

File generated by update-locale

LANG=en_US.UTF-8

$ locale LANG= LC_CTYPE="POSIX" LC_NUMERIC"POSIX" ... LC_IDENTIFICATION="POSIX" LC_ALL=

Adding 'LANG=enUS.UTF-8' to .bashprofile didn't make a difference after logging out and back in.

Running 'sudo /usr/sbin/update-locale LANG=en_US' (for the ISO one) doesn't have any effect either (after logout+login).

$ sudo dpkg-reconfigure locales Generating locales... en_US.ISO-8859-1... up-to-date en_US.UTF-8... up-to-date Generation complete.

Running update-locale after this doesn't work either (not for enUS.UTF-8 nor for enUS.ISO-8859-1).

Any other ideas?

Rodrigo commented Sat May 29 08:58:06 UTC 2010:

Sorry about that, my formatting seems to have been messed up. Hopefully you can still understand the outputs, etc.

Jered commented Tue Jun 01 13:35:54 UTC 2010:

No problem Rodrigo, the CSS on the comments is a little weird, honestly.

On bash_profile, we use it in the articles because it generally doesn't exist on a default image, and it does take precedence over bashrc. You can certainly put those items into bashrc instead, the rationale for using bash_profile is that we don't need to worry about the custom prompt or other settings conflicting with any defaults. Which does, looking at it, conflict with what it says in the article, where it mentions appending to the file. I'll need to fix that, clearly.

On the locale difficulties: More poking around reveals the problem lies in the fact that our recommendation for the sshd_config "UsePAM" setting is "no", and it looks like PAM is what reads the locale file when you log in on Lucid. The options would be to either:

1) Set UsePAM in sshd_config to "yes", or

2) Add a line to the bash_profile (or bashrc file if you prefer) that reads the locale settings file, like so: "source /etc/default/locale"

Honestly, I don't think using PAM is much of a security concern these days, so you should be fine turning UsePAM on. But I'll look into it more and change the article accordingly if I don't turn up any strong security concerns with PAM (I can actually think of some advanced ways PAM can be used to improve security, if used right).

Andy commented Wed Jun 02 05:06:10 UTC 2010:

Thanks for all your help on this Jered. I'm keen to find a solution to this.

Jered commented Wed Jun 02 06:36:13 UTC 2010:

Same here, definitely. I think it should be just a matter of changing "UsePAM" in the "sshd_config" file to "yes" and then restarting ssh. From everything I've seen there's no security hole in using PAM for ssh authentication (indeed, these days it's recommended to use PAM).

If you try changing the UsePAM setting, let me know how it works out. I'll hold off on pushing the change to the articles out until I have confirmation that "UsePAM no" was the culprit.

M289 commented Wed Jun 02 22:45:49 UTC 2010:

FYI: I had some issues with the locale as well.

Turned out the UsePAM no was the culprit. Configuring SSH to "UsePAM yes" solved everything.

Jered commented Wed Jun 02 23:18:18 UTC 2010:

Thank you, M289! Confirmation is good. I'll update the setup articles accordingly.

While I'm at it, since there's been more than one question about it, the section on bash_profile will be changed to use bashrc instead.

Andy commented Wed Jun 02 23:51:08 UTC 2010:

Yep, works great. Thanks again everyone.

M289 commented Sat Jun 05 13:57:30 UTC 2010:

Jered: Thanks!

It's awesome that you guys supply us with these articles, but it's even better than you update them :-D

Katherine commented Mon Jun 28 03:14:04 UTC 2010:

Typo(?): First thing is to confirm what OS we're using. We know we should be using Ubuntu Karmic but let's see:

Should be: ... we should be using Ubuntu Lucid...

woodstock commented Mon Jun 28 05:35:50 UTC 2010:

"First thing (...) Ubuntu Karmic (...)" Not fixed!

Jered commented Mon Jun 28 21:57:22 UTC 2010:

Gah! Fixed again. Hopefully for good. I blame, um, space aliens. Yep. Totally their fault. Not mine for not changing it in an archived copy I was using for an edit, nope.

Griffin commented Sun Jul 18 22:20:58 UTC 2010:

Just an FYI: I had the same locale issues as previously described. I tried flipping UsePAM back to yes, but that didn't work. Only after rebooting my slice did locale report back the right settings.

  • Griffin

Gene Campbell commented Tue Aug 10 23:09:59 UTC 2010:

More excellent documentation. I would suggest putting the aliases in a new file called

./bash_aliases

Since that is what Lucid .bashrc is referencing.

Ryan Gasparini commented Fri Sep 03 00:07:06 UTC 2010:

Shouldn't we leave .bashrc alone and make changes to .profile (unobtrusive) so configurations work for more than one shell?

Jered commented Fri Sep 03 00:57:12 UTC 2010:

Honestly, whatever we pick some people won't be happy, be it .bashrc, .bash_profile, or .profile. ;) Right now we use .bashrc mostly because there is stuff in there by default - that way we steer new Linux users to the .bashrc so they can see there's stuff there already affecting their account, and if they want to they can explore it more later.

You certainly can put the prompt and alias changes into .profile - using the shell-specific .bashrc in the article was a deliberate choice too, since that way we don't have to worry about explaining what changes might not work with what other shells. We also don't have to worry about the standard appearances for different shells - bash typically ends a prompt with "$" and zsh ends with "%", for example, and explaining that in a setup article is a bit distracting for new users.

A decent series on shells is something I want to do someday, certainly. I've always been partial to zsh.

Roeland P commented Wed Oct 13 15:16:27 UTC 2010:

Just like Griffin commented Sun Jul 18 22:20:58 UTC 2010:

I also had the locale problems that although setting the new config the /usr/bin/locale still gave the old POSIX values.

Only after a system reboot showed me the new values. Maybe the new values are applied but the /usr/bin/locale still shows the old values because the change have to be applied and the locale to be refreshed? With a source command or am I 'blablaing out of my neck as we say here in NL'?

Eric Jarvies commented Sun Oct 31 09:33:55 UTC 2010:

I would suggest re-ordering the Ubuntu setup steps as follows:

  1. New User account, wheel group, general setup, and package updating/installing.

  2. Make Slice BACKUP. For those who wish to pay the $5. This provides a fail-safe Ubuntu state that the user can easily return to if they screw something up whilst performing the optional(in the immediate sense) 3rd part of this setup(SSH, etc.). Most people who will be following these instructions, will be new/inexperienced, and thus, much can happen, especially as it relates to SSH, IPTables, etc., so denoting/explaining that the 3rd part of the setup is for additional security, to be done later on, after the user has sowed some oats(like installing/configuring Apache, PostgreSQL, MySQL, and so forth), might be good.

  3. Configure SSH/IPTables/etc.

Eric Jarvies

Jered commented Mon Nov 01 00:37:30 UTC 2010:

The backup advice is good, I'll plan on adding that to the end. The thing about waiting on the general hardening of the system is that the IP addresses owned by hosting providers (ours and our competitors) are regular targets of scans from would-be hackers looking for vulnerabilities. Getting people into the habit of keeping security in mind from the outset is a good thing in that sense. If they put off restricting SSH they're susceptible to brute force password attacks, for example.

Fortunately rebuilding a slice is a quick process, so I'm okay with leaving the security bits at the beginning, then working on package updates and software installations. Recovery is pretty painless when it's still a barebones VPS (and I actually find that rebuilding a slice is faster than restoring a backup).

Vikhyat Korrapati commented Fri Jun 10 18:54:48 UTC 2011:

I was having problems with the locales, turns out I needed to install the language packs.

apt-get install locales
Want to comment?


(not made public)

(optional)

(use plain text or Markdown syntax)