I accidentally upgraded a server to a Debian testing distribution. Now what?
Once upon a time I introduced the following line in our sources.list
file:
deb http://ftp.ch.debian.org/debian/ testing main
I did that because I needed version 3.4 of the octave
package, whereas the latest version in stable (lenny) was 3.2.
Fast-forward a few months, when I have completely forgotten about this change, and I decide to do a full upgrade of that server. I dutifully run
aptitude update
aptitude full-upgrade
And after a while, I discover to my horror that I have just upgraded to a testing distribution (wheezy).
None of the services running on that machine appear broken and everything seems normal. However, what should I reasonably do now? The machine runs only services used internally which, although not mission-critical, would be a pain in the butt if they were to fail.
The machine is hosted in a remote data center to which I have no access, and I am rather unwilling to go to the trouble of reinstalling a server from scratch if I can avoid it.
Note also that I am not a full-time sysadmin. Like any techie in a startup team, I am just the de-facto Linux guy.
Solution 1:
I'd like to know whether downgrading is even possible at all
There is no simple method to downgrade in Debian based distributions.
If you must go back, then it is time to perform a restore from the backups you made.
will I still get security updates?
Yes, but not as fast as you get them on stable.
In the past the testing security team did not learn about embargoed security issues. I believe this may not be an issue anymore, but it still mentions this on the wiki. An embargoed security issue is one which is not publically known, and its existence is to be reported to responsible organizations.. So there may be security patches released for a critical zero-day exploits for stable, but the fix for testing will be delayed.
See this page for details: http://testing-security.debian.net/
The machine runs only services used internally which, although not mission-critical, would be a pain in the butt if they were to fail.
Testing is not stable, this means that they might introduce a change into a package that causes your system to break, that changes the format of configuration files, or many other things. Your system may be working today, but what happens when you run apt-get upgrade to get your security updates in a week, and you also get a new version of a critical service that you depend on, that was a major update and changed the config file format, or introduced a change incompatible with your system.
I would be extremely cautious about running a production system on the testing distro, particularly if you can't easily get to a real console as your question seems to suggest.
Solution 2:
I would be tempted to run your tests and see if they pass. If they do, then it's probably easier to stick with what you have and keep a close eye on it for problems. The best solution is to reinstall and you may have to do that at some time unexpectedly. Make sure you have good backups. Run
dpkg --get-selections > dpkglist.txt
to get a list of the packages on the system and copy the dpkglist.txt to a safe place away from the system.