Debian Upgrade From Wheezy to Jessie

You Only Live Once

This will not be such a YOLO experience, because the whole upgrading from Wheezy to Jessie (stable) went smoothly. I describe the whole process below.

I'm not such a great risk taker as to jump head first to the newest and shiniest things that appear. No, I'm using Debian as my main desktop OS for about a year now and I upgraded to Jessie from Wheezy sometimes in February. It all went great with that upgrade, and I had no issues with the OS ever since - this is the reason that made me confident that the upgrade from Wheezy to Jessie is smooth and easy. 

About The Upgraded Machine

Hardware

The hardware is a dedicated server hosted on Hetzner. I love Hetzner because they offer beefy machines to low prices. This server is a dedicated Intel(R) with an i7 CPU 950 @ 3.07GHz and 24 GB of RAM for which I pay just 34 EUR/month, VAT included.

Software

1. Operating System: Debian Wheezy 7.7
2. Web Servers: nginx and apache, but only nginx is running
3. Programming Languages used: Perl (of course), PHP, Python, nodejs
4. DB engines: MariaDB v10.0, mongodb,

Upgrading from Wheezy to Jessie

If you have valuable services running on your server, or you keep important data on your machine, or you can't afford some downtime, please read the official doc for upgrade (you can find the link in the External Resources section, below in this article). Heck, you should have a look at it anyways, because the points being emphasized there are really strong and are things that we all should incorporate in our daily lives as server owners. I found that documentation a little too verbose for my tastes and I wanted to see how the whole upgrade process works out without guidance. It worked out outstandingly well.

As I said, this process worked smoothly for me and there are huge chances that it'll be the same for you and that is just because of the great people behind the whole Debian project. Thank you Debian guys and girls for this great OS.

Upgrade Process Overview:

1. Check the current configured apt sources
2. Upgrade all the packages to their latest version through apt
3. Modify the /etc/apt/sources.list to contain the stable repositories
4. Upgrade again
5. Upgrade the whole distribution
6. Debian Upgrade From Wheezy to Jessie Process Step by Step
7. Upgrade the packages and cleanup the old ones
8. Reboot and start the custom services

1. Check the current configured apt sources

Check the configured repositories and see if the current distribution version is named wheezy or stable. On this hetzner machine it was named wheezy, so no matter how many times I issued apt-get dist-upgrade, it wouldn't have updated it. You can check this by opening the /etc/apt/sources.list file and see how the lines are looking. For example, I had these: 

deb http://mirror.hetzner.de/debian/packages wheezy main contrib non-free

deb http://mirror.hetzner.de/debian/security wheezy/updates main contrib non-free

The bold wheezy text above says that apt should look for updates in the wheezy repos, not in the stable repos. Let it like that for now. 

WARNING: If they point to the stable version instead of the wheezy version, you'll have to adjust the steps described in this tutorial. Your upgrade process is even simpler, all you have to do is issue an apt-get dist-upgrade.

2. Upgrade all the packages to their latest version through apt

Optional. This step is most probably optional, but since I did it, I include it. Just issue this as root:

apt-get update && apt-get upgrade

3. Modify the /etc/apt/sources.list to contain the stable repositories

Make a backup of your /etc/apt/sources.list file, or just edit the file and comment out all the entries you have, then go to this Debian Sources List Generator and configure the repositories you want to be included. Since Hetzner is located in Germany, I chose the Germany mirrors and now my /etc/apt/sources.list  contains this:

deb http://ftp.de.debian.org/debian stable main non-free

deb http://ftp.debian.org/debian/ stable-updates main non-free

deb http://security.debian.org/ stable/updates main non-free

The generator will considers wheezy as stable and you'll have to replace the wheezy text to either stable, or jessie. I prefer stable.

4. Upgrade again all the packages

Optional. This step is most probably also not necessary, but since I did it, I include this too. Again, as root:

apt-get update && apt-get upgrade

5. Upgrade the whole distribution

This is the big moment has come. As root, without hesitating (because you know, YOLO), issue the upgrading command:

apt-get dist-upgrade

On my server the upgrade took around 20 minutes, including the time the interface was locked waiting for my input and the time it took me to smoke a cigarettes (I had to, because the adrenaline was rushing through my veins).

6. Debian Upgrade From Wheezy to Jessie Process Step by Step

Although the upgrading process is straight forward and without any surprises, you'll have to stay near the console while it happens, because it requires your input: 

6.1 Permissions to restart your services during the upgrade automatically

I allowed it to do it and I have no regrets for doing it.

6.2 Installing the new GRUB

I didn't knew what to do here. After a brief search on the internet, I decided to go with the recommendation from the installer and checked all the partitions. 

It gave some errors telling that it couldn't install GRUB on the /dev/md1 and /dev/md2 partitions and the install went on with no problems in the end. It's probably also OK to install GRUB only on /dev/sda and /dev/sdb:

Chose Continue.

6.3 Disabling password authentication through open-ssh

It looks like the default in Debian Jessie is to not allow root login with password authentication:

While this is a great security improvement, I was logged in remotely with root, with password. Although I have the public key authentication set up for other accounts with sudo rights, I didn't want to risk to be left outside the server, so I chose No for this. I've taken notice of this suggestion and I'll probably update the OpenSSH config later.

6.4 Config files overwriting for the rest of the updated services

During the whole upgrading process, new version of services will be installed. If you've customized the previous services, you'll be prompted whether you wish to install the new config or keep the old one. I chose to keep the customized version for absolutely all the services I was prompted to update.

7. Upgrade the packages and cleanup the old ones

After the whole upgrade process is finished, I issued another apt-get update && apt-get upgrade to make sure everything is up to date. There were no packages updated, but it showed that some packages were installed and no longer needed. 

Issue an apt-get autoremove as root in order to have them removed.

8. Reboot

Because of the above errors when installing GRUB, this was the step to give me the biggest emotions. Given today is Sunday and I don't have that many people relying on my sites, I considered it to be the optimum moment to find out if something goes wrong when rebooting.
It didn't and the server rebooted quite fast (less than a minute)

External Resources

Again, if you're not that much into YOLO-ing, I strongly recommend you to at least have a look at the official docs for upgrading from Wheezy to Jessie.

If you liked the photos in this post and you want to help promoting Debian, check the DebianArt page, grab them and update your social profiles and web pages with those beautiful images.

Conclusions

The whole process to upgrade the Debian production server from Wheezy to Jessie took about an hour and offered no unpleasant surprises. Instead it offers some pleasant ones:

1. Perl version is 5.20.2, the latest stable version at the current moment.
2. kernel version is 3.16.0-4-amd64, which means you I have no more excuses to not start playing with Docker
3. libc is at version 2.19-18 vs 2.13-38 in wheezy
4. And many many more 

Final thoughts

This is my very first step by step guide regarding upgrading an OS. Also, I'm a Perl developer and not a sysadmin, so if you have some observations or want to give advice regarding the above tutorial, please either provide them in the comments below, or send me an email to tudorconstantin __at__ gmail.com to update this article.

Read More

CPAN Pull Request Challenge is Not Really a Challenge

photo by +Darren Song Ng 

What I mean when I say that CPAN PR Challenge is not really a challenge, is that contributing to well known Perl modules is much more accessible for the mere programmer than I expected. And I wouldn't had find out this without participating in the CPAN PR Challenge.

Since the day I started to use Open Source software for my day to day job, I couldn't help myself looking at  people that develop all this free software as if they were some kind of super programmers. They are the next step in the evolution of a programmer. I say this, because in my personal experiences, I found open source software to be of much more high quality, with regards to documentation, tests and coding practices than commercial products. Taking part in the CPAN PR Challenge, made me feel closer to them and who knows, by the end of it, I'll even start one of my own Perl module on CPAN.

Ripening the Low Hanging Fruits

I guess I'm not the only one who feels intimidated by the high quality that Perl modules exhibit with regards to software best practices and I think that's why +Neil Bowers, the guy who initiated and coordinates the whole CPAN PR challenge, put up some guidelines: lower the entry barrier to be accessible to people not involved in open source software until then. 

The rules of the pull request challenge are simple, you have to make a pull request to a Perl module that's assigned to you and is on github. As Neil says, the pull request can be as large or small as you want, but the idea is that you should be contributing to the distribution in some way. This might be documentation, tests, test coverage, fixing known bugs, adding new features, or something else.

The low-hanging fruit I found is related to the documentation on github: while the vast majority of the Perl modules contain their documentation embedded in the source files in the form of POD, github shows the documentation for a module, based on the from READMEs that have to be uploaded together with the repo.

The vast majority of the Perl modules have outstanding documentation, but they don't have a README.md file in the main folder of the module, such that when a developer reaches a github repo of a perl module, he has to dig around to find out what that module does.

Small Modifications, Big Impact

So, basically, we have the documentation already available in the source files and we just have to put it in a file so that github can read it. It would be nice to have this done automatically, preferable at build time. The doc in the module is POD, we need it in markdown, in a file called README.md, because that's what github displays. 

In March I got Perlbrew as a challenge. I use perlbrew heavily whenever I can - on all my dev VMs and also on production wherever that's possible, so I thought this was pretty cool.

My pull request on perlbrew is this. Although the code modifications I made are only 25 lines, the whole pull request says that there 277 lines added. That happens because the whole README.md file is generated.
I also modified some parts of the documentation to add more links into it and you can read below why I did that. 

Have look and see the aspect of the github repo of perlbrew before having a README.md file, and after having a README.md file. Don't you also think it's a much more readable and intuitive module with a proper formatted doc than without?

Positive Side Effects Created by a Good README.md

Besides the fact that it will be easier for a developer to make use of your module, you'll also get the following benefits for free:

1. Search engines love content and your module will provide plenty of it to them
2. Github has a high pagerank and each link from it to your online assets counts as a good backlink
3. With each fork your repo gets, the backlinks to your online properties are multiplied.
4. Considering how the TIOBE index is computed and the above improvements in SEO there are big chances that Perl as a whole will be better positioned from the TIOBE index point of view.

Conclusion

It feels great to be part of the cool community that Perl one is. I feel inspired by you, the developers that backs it in the way that I want to up my level and be like you guys. 

The CPAN PR Challenge is just one of the ways the community does in order to encourage other people to be part of it. Thank you +Neil for starting this and for taking the time and effort to manage it.

PS: If you liked this article, share it.

Read More