Having done free wi-fi I can say that is not true, people will always complain especially in environment like airports. And really especially in you do it in places like airline lounges.
and now you are at an airport with business customers. Which means you need something more reliable and faster than DSL, a failover setup, have to install and maintain cabling going through all kinds of airport infrastructure which you can not reach easily (and often you'll have to go through multi-day procedures just to be able to open up the ceiling), have to protect your infrastructure against customers who will happily flood your network drowning out all other customers as well as your backend infra, etc.. Your real cost will be a *lot* higher than the $3.56 per day.
UNF burninhell was indeed used. The problem was that the binary was (probably manually) fudged so that burninhell would not recognize it as a proper burneye encrypted file. Robert had to manually fix that before burninhell would accept the file and started to brute-force guess the password used.
One if the reasons we are taking so long with all this is that we simply do not know how exactly root was gained. When we do do and we have a fix we will gladly reveal that along with a security advisory detailing how you can protect your systems as well.
Most machines are in colocation facilities and all the normal colo access rules apply to them. That is why I could immediately get to klecker physically (luckily its colo is moving to a new site and we'll get our own access pass for the colo). The only machines that are in locations like peoples homes or dorms are those for which regular physical access is required, for example to experiment with new (or old) architectures.
Lots of people are helping to restore the lost network and computing facilities. People from XS4ALL drove from one side of the country to bring spare junipers and other equipment. The campus is already back online thanks to Virtu. Mail for student is being stored at a new backup MX server courtesy of Terena and zedz.net
Debian is restoring the lost services on klecker. At this moment qa.debian.org is up and running and the non-US and security archives are available as well, although their backend systems have not been restored yet.
Valuable lessons have been learned though: it is very useful to have machines on standby where you can switches services to when needed. Having backups of important data is also really useful (and we could have done a bit better at that. UTwente apparently has good off-site backups of its own data though). And having good insurance is also definitely useful.
Right now we are working on getting everything ready for the potato release (the state of the boot-floppies was one of the major reasons for postponing the freeze). Once that has been finished and potato is released we will probably take a good look at our current design and see how we can improve it. A GUI installation is definately on the TODO-list, as are things like hardware detection and automated installs. We also have access to the installation systems from Corel and Stormix, which should make things easier for us.
Hey, if we are out to change the world and try to get everyone to use Linux we might as well start here and prove that the impossible might in fact not be impossible at all:)
The problem with a `virtual capability' is that sometimes a specific implementation of that ability can introduce unexpected problems. An example is the/usr/lib/sendmail (or/usr/sbin/sendmail now) interface: while all MTAs implement this, they are not exactly the same. As a result debbugs didn't work with qmail originaly since qmail couldn't handle the `name ' style of specifying addresses. So the interface was there, but it was different in a subtle way.
I think what you mean with a `virtual capability' is more like what we do with a `virtual package': with that system one package can `Provide' another (possibly not existing )package and state in that way that it implements the some specific functionality.
I mentioned your project. I was kind of surprised to see there was such a project while it was never mentioned on any debian list as far as I know.
But, to address your points: dpkg and the package system in general will see some modifications once potato has been released. To give two examples: dpkg will be able to log all changes made to packages (longstanding wishlist item), and you will be able to tag a package with a Origin. This allows you to only upgrade to newer versions from the same origin which is very useful if there are multiple versions available.
It has been possible to put a package on hold for ages though, perhaps you missed something?
Slashdot Mirror
FYI: I have been in contact with Loic.
Having done free wi-fi I can say that is not true, people will always complain especially in environment like airports. And really especially in you do it in places like airline lounges.
and now you are at an airport with business customers. Which means you need something more reliable and faster than DSL, a failover setup, have to install and maintain cabling going through all kinds of airport infrastructure which you can not reach easily (and often you'll have to go through multi-day procedures just to be able to open up the ceiling), have to protect your infrastructure against customers who will happily flood your network drowning out all other customers as well as your backend infra, etc.. Your real cost will be a *lot* higher than the $3.56 per day.
UNF burninhell was indeed used. The problem was that the binary was (probably manually) fudged so that burninhell would not recognize it as a proper burneye encrypted file. Robert had to manually fix that before burninhell would accept the file and started to brute-force guess the password used.
One if the reasons we are taking so long with all this is that we simply do not know how exactly root was gained. When we do do and we have a fix we will gladly reveal that along with a security advisory detailing how you can protect your systems as well.
Most machines are in colocation facilities and all the normal colo access rules apply to them. That is why I could immediately get to klecker physically (luckily its colo is moving to a new site and we'll get our own access pass for the colo). The only machines that are in locations like peoples homes or dorms are those for which regular physical access is required, for example to experiment with new (or old) architectures.
The 'almost' is explained later on in the article. The one missing update was a postgres fix which could
never have been used to gain root privileges
Lots of people are helping to restore the lost network and computing facilities. People from XS4ALL drove from one side of the country to bring spare junipers and other equipment. The campus is already back online thanks to Virtu. Mail for student is being stored at a new backup MX server courtesy of Terena and zedz.net
Debian is restoring the lost services on klecker. At this moment qa.debian.org is up and running and the non-US and security archives are available as well, although their backend systems have not been restored yet.
Valuable lessons have been learned though: it is very useful to have machines on standby where you can switches services to when needed. Having backups of important data is also really useful (and we could have done a bit better at that. UTwente apparently has good off-site backups of its own data though). And having good insurance is also definitely useful.
Right now we are working on getting everything ready for the potato release (the state of the
boot-floppies was one of the major reasons for postponing the freeze). Once that has been finished and potato is released we will probably take a good look at our current design and see how we can improve it. A GUI installation is definately on the TODO-list, as are things like hardware detection and automated installs. We also have access to the installation systems from Corel and Stormix, which should make things easier for us.
Hey, if we are out to change the world and try to :)
get everyone to use Linux we might as well start
here and prove that the impossible might in fact
not be impossible at all
The problem with a `virtual capability' is that /usr/lib/sendmail (or /usr/sbin/sendmail now) interface: while all
sometimes a specific implementation of that ability can introduce unexpected problems. An example is the
MTAs implement this, they are not exactly the same. As a result debbugs didn't work with qmail originaly since qmail couldn't handle the `name ' style of specifying addresses. So the interface was there, but it was different in a subtle way.
I think what you mean with a `virtual capability' is more like what we do with a `virtual package': with that system one package can `Provide' another (possibly not existing )package and state in that way that it implements the some specific functionality.
I mentioned your project. I was kind of surprised to see there was such a project while it was never mentioned on any debian list as far as I know.
But, to address your points: dpkg and the package system in general will see some modifications once potato has been released. To give two examples: dpkg will be able to log all changes made to packages (longstanding wishlist item), and you will be able to tag a package with a Origin. This allows you to only upgrade to newer versions from the same origin which is very useful if there are multiple versions available.
It has been possible to put a package on hold for ages though, perhaps you missed something?
Debian is a combination of the names `Deborah'
and `Ian'. It was chosen by Ian Murdock who started the Debian project.
sorry, couldn't resist :)