forum.excito.org

Boy wrote:now that Lenny is out

I tried to get the actual status about the last current release for Bubba Server (ONE). So far I only found an beta release some month ago. Is there a "final" lenny release available?

carl wrote:

ctoo wrote:Another thing: If you do

avahi-browse -v -r -t -a

on Bubbu Server with the Lenny image, you'll see that Bubba Server announces itself as BUBBA|TWO.

Whoops Seems I forgot something there

Did you also notice my preceding comment on the error in backend.pl?

Additionally, with the Lenny image, the yellow led on the front doesn't blink when shutting down Bubba.

dsp76 wrote: I tried to get the actual status about the last current release for Bubba Server (ONE). So far I only found an beta release some month ago. Is there a "final" lenny release available?

I am aware that it is pre-release. I would be happy with a sarge image, if there would be separate system and "personal data" partitions. This was announced to be included with a etch image, which was not realized. http://forum.excito.net/viewtopic.php?f=1&t=861

So I am waiting for the lenny image to be finally released. The pre-release of lenny was in May. My question was just, if there are any plans for any updates or the final release etc.

Yes, I would be happy if the features of the lenny distribution were frozen, and the bugs that have been found by testers fixed.

I am still using the original Version 0.52.2-1 on my "production" server - It has an uptime of 305 days 00:23:14. My test/backup/development Bubba 0.99.4-1 has been up for 22 days 05:55:41 with few problems.

I know that you are busy with the newer products, but it would be really good if Excito could get lenny out with the same reliability as Version 0.52.2-1...

/Tim

Hi all,

Sorry for the late reply.

Regarding future development of Bubba|SERVER (b1). I'm sorry to say that Excito unfortunately have no resources for new feature development on that platform. The features available in the latest stable release is what can be expected.

With that said, we will do a stable Lenny based release, that will replace the current Sarge based version. We will then support that version with periodical security updates until Lenny is no longer supported by Debian.

Unfortunately the last fixes on the Lenny based version is taking a bit longer than what we would have liked. And its no secret that atm all our development focus is on B2 WLAN which has been quite delayed for various reasons. I can only apologize for that.

I hope this somewhat clears up Excito position on Bubba|SERVER future.

/Tor

Another issue:

The Lenny image for Bubba server is using the "host" package. Unfortunately, the output of this utility seems to be incompatible with /usr/lib/avahi/avahi-daemon-check-dns.sh which is called by /etc/network/if-up.d/avahi-daemon. The consequence is that a file /var/run/avahi-daemon/disabled-for-unicast-local will be created which will disable the startup of the avahi-daemon.

To fix this, you should do

aptitude install bind9-host

ctoo wrote:Another issue:

The Lenny image for Bubba server is using the "host" package. Unfortunately, the output of this utility seems to be incompatible with /usr/lib/avahi/avahi-daemon-check-dns.sh which is called by /etc/network/if-up.d/avahi-daemon. The consequence is that a file /var/run/avahi-daemon/disabled-for-unicast-local will be created which will disable the startup of the avahi-daemon.

To fix this, you should do

aptitude install bind9-host

I forgot: after executing the above, you should do the following as well:

Once I had fixed the avahi installation, I turned to testing Amarok on my Kubuntu laptop against mt-daapd on Bubba Server. However, it wouldn't play the music offered by mt-daapd on Bubba server. Amarok simply hang indefinitely as if Bubba didn't provide it with the music files it requested.

I then added the following line to /etc/mt-daapd.conf: and restarted mt-daapd: And Amarok is now able to play music from Bubba!

I'm guessing that mt-daapd is attempting to do format conversion (from ogg to wav) by default, but the Bubba Server lenny image doesn't include the ffmpeg package that is required for this.

I've now added to my /etc/apt/sources.list and it appears that there is a small set of updates available.

Is it safe to run aptitude update and aptitude safe-upgrade with this?

As far as I can tell, the lenny image you have provide use a somewhat different versioning scheme than the current packages in the official Debian lenny. This seems to be the case for mediatomb, for example. Have you branched out from Debian lenny and done your own modifications to the packages?

ctoo wrote:I've now added

Code: Select all

deb http://ftp.se.debian.org/debian lenny main

to my /etc/apt/sources.list and it appears that there is a small set of updates available.

Is it safe to run aptitude update and aptitude safe-upgrade with this?

As far as I can tell, the lenny image you have provide use a somewhat different versioning scheme than the current packages in the official Debian lenny. This seems to be the case for mediatomb, for example. Have you branched out from Debian lenny and done your own modifications to the packages?

Regarding mediatomb it's really a mess (their versoning stuck a long time, so svn revisions was pointed); and there are local modifications made (mostly for configure file).

/Carl

carl wrote:

ctoo wrote:I've now added

Code: Select all

deb http://ftp.se.debian.org/debian lenny main

to my /etc/apt/sources.list and it appears that there is a small set of updates available.

Is it safe to run aptitude update and aptitude safe-upgrade with this?

As far as I can tell, the lenny image you have provide use a somewhat different versioning scheme than the current packages in the official Debian lenny. This seems to be the case for mediatomb, for example. Have you branched out from Debian lenny and done your own modifications to the packages?

Regarding mediatomb it's really a mess (their versoning stuck a long time, so svn revisions was pointed); and there are local modifications made (mostly for configure file).

/Carl

Ok, but mediatomb is not the only package that deviated from the official Debian lenny. What made you decide that you couldn't do with the packages that came with Debian lenny? Do you have a complete list of the packages that differ between the official Debian lenny and the lenny image for Bubba Server?

ctoo wrote:

ctoo wrote:Another issue:

The Lenny image for Bubba server is using the "host" package. Unfortunately, the output of this utility seems to be incompatible with /usr/lib/avahi/avahi-daemon-check-dns.sh which is called by /etc/network/if-up.d/avahi-daemon. The consequence is that a file /var/run/avahi-daemon/disabled-for-unicast-local will be created which will disable the startup of the avahi-daemon.

To fix this, you should do

aptitude install bind9-host

I forgot: after executing the above, you should do the following as well:

Code: Select all

rm /var/run/avahi-daemon/disabled-for-unicast-local
rm /var/run/avahi-daemon/checked_nameservers
/etc/init.d/avahi-daemon restart

And that wasn't all: It seems that the DNS servers of my ISP actually return a valid SOA record for the local domain. Hence, /usr/lib/avahi/avahi-daemon-check-dns.sh will still disable Avahi when booting. Judging from bug reports for Ubuntu and Debian, this seems to be a frequently occuring problem with Avahi. I found a statement saying that this is solved with the Avahi 0.6.25 that is shipped with Ubuntu 9.10, and indeed Avahi is working flawlessly on my Kubuntu 9.10 laptop. However, I was unable to find any changes in the source code for Avahi 0.6.25 and 0.6.24 that would indicate that this problem has been fixed. I didn't check the Ubuntu specific changes of the package, though. In any case, the lenny image for Bubba Server only contains Avahi 0.6.23, so I therefore had to set AVAHI_DAEMON_DETECT_LOCAL=0
in /etc/default/avahi-daemon (I have no unicast nameserver on my LAN).

ctoo wrote:

carl wrote:

ctoo wrote:I've now added

Code: Select all

deb http://ftp.se.debian.org/debian lenny main

to my /etc/apt/sources.list and it appears that there is a small set of updates available.

Is it safe to run aptitude update and aptitude safe-upgrade with this?

As far as I can tell, the lenny image you have provide use a somewhat different versioning scheme than the current packages in the official Debian lenny. This seems to be the case for mediatomb, for example. Have you branched out from Debian lenny and done your own modifications to the packages?

Regarding mediatomb it's really a mess (their versoning stuck a long time, so svn revisions was pointed); and there are local modifications made (mostly for configure file).

/Carl

Ok, but mediatomb is not the only package that deviated from the official Debian lenny. What made you decide that you couldn't do with the packages that came with Debian lenny? Do you have a complete list of the packages that differ between the official Debian lenny and the lenny image for Bubba Server?

I've now checked the source for the dovecot package. In Debian lenny it has the version number 1:1.0.15-2.3, whereas the version used in Bubba lenny is 1:1.0.15-2.3ex1. The only difference between the two is that the configuration file used in Bubba lenny has an explicit setting for the "mail_location", which means that the algorithm implemented by dovecot for automatic detection of the mail dir is disabled. I'm guessing this was done because the dovecot documentation states that the automatic detection will fail if a user has no mail dir created. However, if you move the creation of the ~/Mail dir into backend.pl, I believe that the dovecot automatic detection will actually work as long as new users are registered through the web admin interface. This way you wouldn't need to build your own version of the dovecot packages.

My worries are, of course, that relying on excito specific packages are more likely to introduce conflicts with future debian updates. Additionally, such packages puts extra workload on excito and hence lowers the chances that we'll be able to keep Bubba Server up-to-date with Debian.

tor wrote: With that said, we will do a stable Lenny based release, that will replace the current Sarge based version.
/Tor

Hi Tor, thanks for update - do you have any rough estimate for finishing that?

ctoo wrote:

ctoo wrote:

carl wrote: Regarding mediatomb it's really a mess (their versoning stuck a long time, so svn revisions was pointed); and there are local modifications made (mostly for configure file).

/Carl

Ok, but mediatomb is not the only package that deviated from the official Debian lenny. What made you decide that you couldn't do with the packages that came with Debian lenny? Do you have a complete list of the packages that differ between the official Debian lenny and the lenny image for Bubba Server?

I've now checked the source for the dovecot package. In Debian lenny it has the version number 1:1.0.15-2.3, whereas the version used in Bubba lenny is 1:1.0.15-2.3ex1. The only difference between the two is that the configuration file used in Bubba lenny has an explicit setting for the "mail_location", which means that the algorithm implemented by dovecot for automatic detection of the mail dir is disabled. I'm guessing this was done because the dovecot documentation states that the automatic detection will fail if a user has no mail dir created. However, if you move the creation of the ~/Mail dir into backend.pl, I believe that the dovecot automatic detection will actually work as long as new users are registered through the web admin interface. This way you wouldn't need to build your own version of the dovecot packages.

My worries are, of course, that relying on excito specific packages are more likely to introduce conflicts with future Debian updates. Additionally, such packages puts extra workload on excito and hence lowers the chances that we'll be able to keep Bubba Server up-to-date with Debian.

I wanted to understand whether the Bubba specific changes were really needed or could perhaps be handled differently. Again, my concern is that the more deviations from Debian Lenny, the more problematic it will be to keep up with developments in Debian. I've therefore also checked the other packages that differed from Debian lenny and came up with a few proposals - I hope you don't mind this kind of input:

openssl: libssl0.9.8 seems to contain official debian changes, but they seem to be newer than those in the official Debian Lenny. Bubby Lenny is using version 0.9.8g-15+lenny5 whereas Debian lenny is using 0.9.8g-15+lenny3. Can't see why there should be a difference here.

tiff_3.8.2: Bubba Lenny is using version 3.8.2-11.2 whereas Debian Lenny is using version 3.8.2-11. Seems like Bubba Lenny has included a valid later revision from Debian, but not from Debian Lenny. Why?
Changelog mentions CVE-2009-2347 and CVE-2009-2285.

cups: Bubba Lenny is using version 1.3.8-1lenny4.1ex1 whereas Debian Lenny is using version 1.3.8-1+lenny6. The changelog reveals that two security fixes were not included in Bubba Lenny. The applied versioning will also most likely mean that no updates from Debian Lenny will be accepted. Changes in Bubba Lenny version: rules allow /usr/lib/cups/backend-available/serial to be readable to group/others - why? Bubba version changes cupsd.conf in order to restrict access to cups services. Perhaps this could be handled in an upstream version by a "Restrict to local network?" question for debconf?

ilohamail: Bubba Lenny is using version 0.8.14-0rc3sid6ex1 whereas Debian Lenny is using version 0.8.14-0rc3sid6. Changes in Bubba version: change in debian/patches/05-rc3.dpatch to restrict index.php to only gain access to localhost:143. Could this be done elsewhere? Perhaps the patch is of little value and could be avoided? ilohamail.configure changed to use hardcoded input for webserver_type and weblocation. Couldn't this be done by means of debconf if upstream agrees? Is the update of swedish translation really needed?

samba: Bubba Lenny is using version 3.2.5-4ex3 whereas Debian Lenny is using version 3.2.5-4lenny6. Only configuration changes in Bubba version. Two of the changes could have been handled by debconf. Other changes could be handled by separate run-once script or by debconf after discussion with upstream. Several bug fixes absent from Bubba version. Seems safe to upgrade from Bubba Lenny version to Debian Lenny version.

udev: Bubba Lenny is using version 0.114-2 whereas Debian Lenny is using version 0.125-7+lenny3. Unclear whether an upgrade is safe.

mediatomb: Bubba Lenny is using version 1:0.11.0-3ex22+b1lenny3 whereas Debian Lenny is using version 0.11.0-3. Changes in Bubba version: Configuration changes, only. config.xml could probably be updated from debconf if upstream agrees. Perhaps also absent/changed files could be sent upstream? The applied versioning will mean that no updates from Debian Lenny will be accepted.

mt-daapd: Bubba Lenny is using version 1:0.9~r1696.dfsg-4ex2 whereas Debian Lenny is using version 0.9~r1696.dfsg-6lenny2. A couple of bug fixes not included in Bubba Lenny. Could make sense to send init script and postinst changes upstream. Perhaps upstream could be talked into using debconf for setting the location of mediafiles, adminpassword, servername, scan_type. Plugins should be configured in a postinst script based on what plugins are actually available. The applied versioning will mean that no updates from Debian Lenny will be accepted.

postfix: Bubba Lenny is using version 2.5.5-1.1ex1 whereas Debian Lenny is using version 2.5.5-1.1.
Configuration changes in Bubba version, only. Strange that main.cf.in has hardcoded mynetworks=192.168.0.0/28. This is not guaranteed to be valid in all installations. Perhaps backend.pl changes this later on? Didn't check this. /etc/postfix/bubbadomains added, but this file is empty! Why?
Proposal: Move all this to backend.pl which is using postconf anyway and stay with the Debian Lenny version.

proftpd: Bubba Lenny is using version 1.3.1-17ex1 whereas Debian Lenny is using 1.3.1-17lenny2.
Bubba Lenny version is missing Debian Lenny updates. Other changes in Bubba Lenny: Changes to avoid creation of ftp users home dir. Should this be communicated upstream?
Bubba specific changes to proftpd.conf. Could this be done in a separate script in the Bubba package or through depconf (if upstream agrees)? As welcome.msg would need to be updated, too, a separate script seems best. Seems safe to upgrade from Bubba Lenny version to Debian Lenny version.

In summary, I can see that there is good deal of configuration changes that the excito team has had to do as the configuration from the upstream packages were not suitable for Bubba Lenny. In the ideal world, a tool like debconf would be able to do this kind of custom setup automatically without deviating from the Debian Lenny packages. In fact, in some of the above cases, it seems that very few changes would have to be moved upstream in order for this to be possible. In other cases, like the samba or postfix configuration, the deviations from the Debian package are probably too large for this to be practical. In such a case, an alternative could be a set of run-once script (early in the startup process or right after a fresh install) that edited the appropriate configuration files - just like a user would have to do manually if he/she was not satisfied with the configuration options provided by the Debian packages.

I feel that deviating from the Debian packages is something that large communities or organizations can afford. Small development teams will gain more (in the sense of reduced long-term maintenance efforts) from pushing upstream to include the required changes (preferably through the use of debconf), or alternatively, editing (e.g. by means of a script) the configuration files after package installation.