Archive for April, 2012

‘sudo’ vs using a root password

There seems to be a lot of confusion about the use of “sudo” vs using a root password.  It’s a lot simpler than many make it out to be.

  • On a system that uses a root password, all administrators use a shared root password.
  • On a system that uses “sudo”, all administrators use their own passwords.
  • There is no reason why you can’t do both.

Some people argue about a Linux distribution’s default setting, when they could simply change the setting after installation and forget about it.

  • To enable a root password:
    $ sudo passwd root
  • To disable a root password:
    $ sudo passwd -l root
  • To start using sudo:
    # apt-get install sudo
    # adduser username sudo
  • To stop using sudo:
    # gpasswd -d username sudo
    # apt-get remove --purge sudo
    (optional)
  • To run a “su-like” shell using “sudo”:
    $ sudo -s (runs a normal shell)
    or
    $ sudo -i (runs a login shell)

Personally, I have gotten used to disabling my root password and the using either sudo -i or ssh root@hostname.  That’s one less password for me to remember, and one less password that can be probed on the network.

But you don’t have to be like me… you do what feels right to you!

Debian’s “dist-upgrade”

There seems to be a common misconception about Debian’s package manager “apt”, that the command “dist-upgrade” is used to upgrade to a new release. It is, but it isn’t. I wanted to clarify that here.

Basically, there are 4 things that you might want to do as part of upgrading a system.

  • apt-get update – updates the list of available packages and versions
  • apt-get upgrade – upgrade packages that you already have
  • apt-get dist-upgrade – upgrade packages that you already have, PLUS install any new dependencies that have come up
  • edit the sources files – change the release that you are tracking

That means that to freshen up your packages to the latest versions on your current release, you should do “apt-get update && apt-get dist-upgrade“. On some systems that track “testing”, which changes often, I do this almost daily.

When you’re ready to “really upgrade” to a new release, you edit your sources files in /etc/apt/sources and change the release names. If the source lists contain proper release names, like “etch”, “lenny”, “squeeze” or “wheezy”; then you change these names to the new release that you want (see http://www.debian.org/releases/). If the source lists contain symbolic names like “stable”, “testing” and “unstable”, you do not need to change anything. When a new release is ready, the Debian people will change the symbols to point to the new release names. For example, right now, stable=squeeze and testing=wheezy.

Note 1 – “unstable” never points to a named release… it’s the pre-release proving ground for packages, used before are ready for inclusion in the testing release.

Note 2 – Don’t let these symbolic names fool you:

  • “Stable” means “old, tried, tested, and rock solid”.  It’s a very conservative choice.
  • “Testing” does not mean “chaotic”. It is roughly the equivalent of Red Hat’s Fedora. It’s new stuff, and each package changes on its own schedule, but they usually play well together.
  • “Unstable” is not nearly as unstable as the name implies. It’s like a beta release that may be updated daily.

After your source lists look OK, you do the same thing you’ve always done: “apt-get update && apt-get dist-upgrade“”apt-get update && apt-get dist-upgrade“.

If you’re running Ubuntu, the release names are at http://releases.ubuntu.com/. And they’ve made a nice wrapper script called “do-release-upgrade” that basically edits your source lists and does the dist-upgrade for you (it also does some other nice steps, like letting you review the changes).

So there it is… fear not the “dist-upgrade”. In fact, most of the time, it is what you’ll want to run. It will make sure that you have all of the dependencies that you need.

Go to Top