devil-linux-develop — developer discussions

Re: [Devil-linux-develop] hardware detection

[Heiko Z. <he...@zu...>]

Jean-Luc Parouty wrote:

> Hi,
> Concerning hardware... is there any news concerning sata support ?
> I have two dell optiplex 280 in my office, waiting for a sata 
> Devil...  ;-)
> (There is a bios/compatibility option, but it doesn't works fine...)


We currently support whatever the linux kernel (2.4 in this case) supports.
Is it possible that you have to load a specific module?

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] hardware detection

[Jean-Luc P. <Jea...@ib...>]

Hi,
Concerning hardware... is there any news concerning sata support ?
I have two dell optiplex 280 in my office, waiting for a sata Devil...  ;-)
(There is a bios/compatibility option, but it doesn't works fine...)
Regards,
    - pjluc

-- 
Jean-Luc Parouty - Phone: +33 4 387 823 90
Institut de Biologie Structurale-CNRS (UMR 5075)/CEA/UJF - IBS
41 Av. Jules Horowitz - 38027 Grenoble Cedex 1 - France

Re: [Devil-linux-develop] hardware detection

[Roland P. <rp...@ne...>]

On Sunday 13 March 2005 17:26, Heiko Zuerker wrote:
> Roland Pabel wrote:
> >Hi,
[...]
>
> It will only work for PCI devices, but most of our users should use PCI
> anyway.
yeah, I don't think probing for isa cards is necessary any more
> We already have the pci database included, it's here: /usr/share/pci.ids .
> Of course we would need to run the script twice, once in initrd to
> detect all the SCSI controllers and later for the network cards and
> whatever else is in the system.
right, although SCSI controller modules should be put into the initrd by the 
user just to be sure...
> Did you get a chance to try the script?
not yet, I'll play around with it this evening. I'm curious if this wouldn't 
better be implemented using sysfs (instead of procfs), since that is what 
sysfs was designed for...
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

Re: [Devil-linux-develop] hardware detection

[Heiko Z. <he...@zu...>]

Roland Pabel wrote:

>Hi,
>I recently read an article in the linux-user magazine about automatic module 
>loading. To say it short: I didn't know it was so simple :-)
>The author Mikro Doelle showed a 80 line bash script which loads modules for 
>hardware it finds listed in the proc filesystem and is recognized by pci-ids 
>database:
>http://www.mirko-doelle.de/vdr/hwdetect
>I think we could easily integrate an adapted version (after some perfomance 
>tuning perhaps) into the boot process, doesn't even need to be in the etc 
>image.
>  
>

It will only work for PCI devices, but most of our users should use PCI 
anyway.
We already have the pci database included, it's here: /usr/share/pci.ids .

Of course we would need to run the script twice, once in initrd to 
detect all the SCSI controllers and later for the network cards and 
whatever else is in the system.
Did you get a chance to try the script?

And we should also translate the commentss into english ;-)

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] patch to get postfix to work with saslauthd

[Heiko Z. <he...@zu...>]

Friedrich Lobenstock wrote:

> Hi!
>
> I was just trying to get postfix on DL 1.2.3 to use saslauth with 
> rimap authentication.
>
> I did fail to configure smtpd to use the saslauthd. As a workaround I 
> had to do:
>
> cp -a /usr/lib/sasl2/ /tmp/
> mount -t shm shm /usr/lib/sasl2/
> cp -a /tmp/sasl2/* /usr/lib/sasl2/
>
> to get a writeable /usr/lib/sasl2/ directory. There I could then put 
> the "smtpd.conf" file to tell postfix to use saslauthd.
>
> I found that someone created a patch so this file would then be stored 
> at eg. /etc/postfix/sasl which is definitely writeable on DL.
>
> Get the patch at 
> <http://archives.neohapsis.com/archives/postfix/2005-03/0397.html>
>
> Following that thread I've come to "plan B" (if you don't like to add 
> a patch):
> step 1)
>   Add
>     export SASL_PATH=/etc/postfix/sasl:/usr/lib/sasl2
>   somewhere at the start of /etc/init.d/postfix. Preferably
>   direct after "PACKAGE_NAME=POSTFIX".
>
>
> step 2)
>   Update postfix config by running
>      postconf -e "$(postconf -d | grep import_environment | sed \
>      -e "s/$/ SASL_PATH/")"
>
> Now one can put postfix sasl config files like "smtpd.conf" at 
> /etc/postfix/sasl as the original destination /usr/lib/sasl2 is quite 
> write protected as it's on the CD.
>
> PS: This is just step closer as I now got saslauthd talk to the imap 
> server BUT there some other problems there. Updates to come...
>
I did a quick test with the patch and it fails only in 1 place for the 
currently used Postfix 2.1.5. Postfix 2.2.0 has 2 rejects.
This wouldn't be hard to fix.

Do you want us to wait until you're further down the road with your 
implementation ?

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

[Devil-linux-develop] hardware detection

[Roland P. <rp...@ne...>]

Hi,
I recently read an article in the linux-user magazine about automatic module 
loading. To say it short: I didn't know it was so simple :-)
The author Mikro Doelle showed a 80 line bash script which loads modules for 
hardware it finds listed in the proc filesystem and is recognized by pci-ids 
database:
http://www.mirko-doelle.de/vdr/hwdetect
I think we could easily integrate an adapted version (after some perfomance 
tuning perhaps) into the boot process, doesn't even need to be in the etc 
image.
cu
Roland
-- 
ICQ UIN 49339118	Linux Counter #88774
GPG-Key 1024D/59C6AFA6 2003-02-07 Roland Pabel <ro...@pa...>

[Devil-linux-develop] patch to get postfix to work with saslauthd

[Friedrich L. <fl...@fl...>]

Hi!

I was just trying to get postfix on DL 1.2.3 to use saslauth with rimap 
authentication.

I did fail to configure smtpd to use the saslauthd. As a workaround I had to do:

cp -a /usr/lib/sasl2/ /tmp/
mount -t shm shm /usr/lib/sasl2/
cp -a /tmp/sasl2/* /usr/lib/sasl2/

to get a writeable /usr/lib/sasl2/ directory. There I could then put the 
"smtpd.conf" file to tell postfix to use saslauthd.

I found that someone created a patch so this file would then be stored at eg. 
/etc/postfix/sasl which is definitely writeable on DL.

Get the patch at <http://archives.neohapsis.com/archives/postfix/2005-03/0397.html>

Following that thread I've come to "plan B" (if you don't like to add a patch):
step 1)
   Add
     export SASL_PATH=/etc/postfix/sasl:/usr/lib/sasl2
   somewhere at the start of /etc/init.d/postfix. Preferably
   direct after "PACKAGE_NAME=POSTFIX".


step 2)
   Update postfix config by running
      postconf -e "$(postconf -d | grep import_environment | sed \
      -e "s/$/ SASL_PATH/")"

Now one can put postfix sasl config files like "smtpd.conf" at /etc/postfix/sasl 
as the original destination /usr/lib/sasl2 is quite write protected as it's on 
the CD.

PS: This is just step closer as I now got saslauthd talk to the imap server BUT 
there some other problems there. Updates to come...

-- 
MfG / Regards
Friedrich Lobenstock
____________________________________________________________________
Friedrich Lobenstock                       Linux Services Lobenstock
URL: http://www.lsl.at/                         Email: fl...@fl...
____________________________________________________________________

Re: [Devil-linux-develop] nsswitch/nss_ldap with nouser/nogroup files

[Heiko Z. <he...@zu...>]

Jean-Luc Parouty wrote:

>
> Hello,
> - On the cvs 1.2.x distribution, it seems that the 
> build/scripts/nss_ldap script is "lost" in
> scripts/configuration instead of build/scripts...

really?
I take a look at it tomorrow.

> -There is many nouser/nogroup files, result blocks the boot if we use 
> nss_ldap, because when te setfileperm start (for example), there is no 
> network, and by default nss_ldap works in "hard" mode (bind_policy 
> hard). Anyway it could happend during upgrade...
> -> Solution consist to set the bind_policy from "hard" to "soft"...


I'm not really sure what you're talking about, but I never used nss_ldap ...

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

[Devil-linux-develop] nsswitch/nss_ldap with nouser/nogroup files

[Jean-Luc P. <Jea...@ib...>]

Hello,
- On the cvs 1.2.x distribution, it seems that the 
build/scripts/nss_ldap script is "lost" in
scripts/configuration instead of build/scripts...
-There is many nouser/nogroup files, result blocks the boot if we use 
nss_ldap, because when te setfileperm start (for example), there is no 
network, and by default nss_ldap works in "hard" mode (bind_policy 
hard). Anyway it could happend during upgrade...
-> Solution consist to set the bind_policy from "hard" to "soft"...

Regards,
    - pjluc

-- 
Jean-Luc Parouty - Phone: +33 4 387 823 90
Institut de Biologie Structurale-CNRS (UMR 5075)/CEA/UJF - IBS
41 Av. Jules Horowitz - 38027 Grenoble Cedex 1 - France

Re: [Devil-linux-develop] Idea for 1.3 ...

[Jean-Luc P. <Jea...@ib...>]

Heiko Zuerker wrote:

> (...)
>
>>I try to add pam and ldap and I have a funny problem...
>>- openldap need cyrus-sasl
>>- cyrus-sasl need openldap
>>    
>>
>
>Currently it works without those dependencies, are you changing something
>in those scripts?
>  
>
Of course :-)
I patched the cyrus-sasl script to add the --with-pam and --with-ldap to 
the configure
If we want to make a pop/imap server with an ldap authentification, we 
need the --with-ldap

>>So, the only way I found is to compile cyrus too times, one without ldap
>>(before openldap) and a second time, during the build process...
>>Is it the good appoach ?
>>I'd prefer to be sure before sending my pam/ldap  patches ;-)
>>    
>>
>
>I'd prefer if we can avoid doing something like this.
>
Sure, but I'm alfraid that this problem could appear somewere else...

Sorry, but I have another question... I just receive two Dell optiplex 
280, with... SATA
The bios "combination" mode is supposed to give an ide compatibility, 
but it doesn't works
fine... (I will re-test my cvs version tomorow)

Is there something new for sata support in the 2.6.x kernel of 1.3 ?
    - pjluc

-- 
Jean-Luc Parouty - Phone: +33 4 387 823 90
Institut de Biologie Structurale-CNRS (UMR 5075)/CEA/UJF - IBS
41 Av. Jules Horowitz - 38027 Grenoble Cedex 1 - France

Re: [Devil-linux-develop] Idea for 1.3 ...

[Heiko Z. <he...@zu...>]

> Heiko Zuerker wrote:
>
>
>>>>>> Let's not remove the option for including stuff on the CD.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> How long before we have to switch from a CD distro to a DVD
>>>>> distro? If we duplicate enough packages, it may be sooner than we
>>>>> want!  :-)
>>>>>
>>>>>
>>>>>
>>>> I don't mean duplicate packages, but give the choice in menuconfig
>>>> to either include it on the CD directly, or as a tarball.
>>>>
>>>>
>>> What would be the default selections for the ISO's for download on
>>> sourceforge and the FTP site?
>>>
>>>
>>
>> That's the big question which we would have to figure out.
>> It's important that we choose what most users want.
>>
>>
>>
>>
> Hum, there is a lot of place on a cd... so there is no space problem
> today  ;-) Only have data on the local disk and a fully static cd is a nice
>  simplification...
>
> If we want to build easly some small Devil (for usb key ?) , we could
> just define some differents profiles and have a very simple build
> procedures... I think that actualy, there is just one "default" profile...
> we could imagine many profiles: firewall, ldap server, apache server, etc.
>  So, on the ftp, we could propose all of the *predefined* Devil... (from
> mini Devil to Maxi Devil ;-)
>
> "...And, now, something totaly different ;-)"

You see, the discussions already start. ;-)
I think we should do a BYOFDL.

> I try to add pam and ldap and I have a funny problem...
> - openldap need cyrus-sasl
> - cyrus-sasl need openldap

Currently it works without those dependencies, are you changing something
in those scripts?

> So, the only way I found is to compile cyrus too times, one without ldap
> (before openldap) and a second time, during the build process...
> Is it the good appoach ?
> I'd prefer to be sure before sending my pam/ldap  patches ;-)

I'd prefer if we can avoid doing something like this.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] Idea for 1.3 ...

[Jean-Luc P. <Jea...@ib...>]

Heiko Zuerker wrote:

>>>>>Let's not remove the option for including stuff on the CD.
>>>>>
>>>>>          
>>>>>
>>>>How long before we have to switch from a CD distro to a DVD distro?
>>>>If we duplicate enough packages, it may be sooner than we want!  :-)
>>>>
>>>>        
>>>>
>>>I don't mean duplicate packages, but give the choice in menuconfig to
>>>either include it on the CD directly, or as a tarball.
>>>      
>>>
>>What would be the default selections for the ISO's for download on
>>sourceforge and the FTP site?
>>    
>>
>
>That's the big question which we would have to figure out.
>It's important that we choose what most users want.
>
>  
>
Hum, there is a lot of place on a cd... so there is no space problem 
today  ;-)
Only have data on the local disk and a fully static cd is a nice 
simplification...

If we want to build easly some small Devil (for usb key ?) , we could 
just define some differents profiles and have a very simple build 
procedures...
I think that actualy, there is just one "default" profile... we could 
imagine many profiles: firewall, ldap server, apache server, etc.
So, on the ftp, we could propose all of the *predefined* Devil... (from 
mini Devil to Maxi Devil ;-)

"...And, now, something totaly different ;-)"

I try to add pam and ldap and I have a funny problem...
    - openldap need cyrus-sasl
    - cyrus-sasl need openldap

So, the only way I found is to compile cyrus too times, one without ldap 
(before openldap) and a second time, during the build process...
Is it the good appoach ?
I'd prefer to be sure before sending my pam/ldap  patches ;-)
    - pjluc

-- 
Jean-Luc Parouty - Phone: +33 4 387 823 90
Institut de Biologie Structurale-CNRS (UMR 5075)/CEA/UJF - IBS
41 Av. Jules Horowitz - 38027 Grenoble Cedex 1 - France

Re: [Devil-linux-develop] Idea for 1.3 ...

[Heiko Z. <he...@zu...>]

>>>> Let's not remove the option for including stuff on the CD.
>>>>
>>>
>>> How long before we have to switch from a CD distro to a DVD distro?
>>> If we duplicate enough packages, it may be sooner than we want!  :-)
>>>
>>
>> I don't mean duplicate packages, but give the choice in menuconfig to
>> either include it on the CD directly, or as a tarball.
>
> What would be the default selections for the ISO's for download on
> sourceforge and the FTP site?

That's the big question which we would have to figure out.
It's important that we choose what most users want.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] Idea for 1.3 ...

[Bruce S. <bw...@ar...>]

> >> Let's not remove the option for including stuff on the CD.
> >
> > How long before we have to switch from a CD distro to a DVD distro?
> > If we duplicate enough packages, it may be sooner than we want!  :-)
> 
> I don't mean duplicate packages, but give the choice in menuconfig to
> either include it on the CD directly, or as a tarball.

What would be the default selections for the ISO's for download on
sourceforge and the FTP site?

 - BS

Re: [Devil-linux-develop] Idea for 1.3 ...

[Heiko Z. <he...@zu...>]

>>>>> Yeah, that would be too much work.  If we decided to go this
>>>>> route, we could keep it simple by changing server packages to only
>>>>> run from the hard drive (CD is not even an option).  But I'm not
>>>>> sure how many people would complain that's not secure enough.
>>>>
>>>> I would complain. ;-)
>>>>
>>>
>>> There's always one in the crowd ...  :-)
>>>
>>
>> I'm just glad that I have a loud enough voice here. ;-)
>> Let's not remove the option for including stuff on the CD.
>>
>
> How long before we have to switch from a CD distro to a DVD distro?
> If we duplicate enough packages, it may be sooner than we want!  :-)

I don't mean duplicate packages, but give the choice in menuconfig to
either include it on the CD directly, or as a tarball.

>> We should also take this opportunity to make sure our install script
>> support both ways, without adding to much overhead. Something like
>> installing into a temporary location and a generic script copies all
>> the stuff into the right place, depending on the configuraton options.
>
> What's the current status of 1.3?  What still doesn't compile?

I actually can't tell, most of the stuff does compile by now.
I don't have much time at the moment, so I didn't work a lot on 1.3

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] Idea for 1.3 ...

[Bruce S. <bw...@ar...>]

> >>> Yeah, that would be too much work.  If we decided to go this route,
> >>> we could keep it simple by changing server packages to only run from
> >>> the hard drive (CD is not even an option).  But I'm not sure how many
> >>> people would complain that's not secure enough.
> >>
> >> I would complain. ;-)
> >
> > There's always one in the crowd ...  :-)
> 
> I'm just glad that I have a loud enough voice here. ;-)
> Let's not remove the option for including stuff on the CD.

How long before we have to switch from a CD distro to a DVD distro? 
If we duplicate enough packages, it may be sooner than we want!  :-)

> We should also take this opportunity to make sure our install script
> support both ways, without adding to much overhead. Something like
> installing into a temporary location and a generic script copies all the
> stuff into the right place, depending on the configuraton options.

What's the current status of 1.3?  What still doesn't compile?

 - BS

Re: [Devil-linux-develop] Idea for 1.3 ...

[Heiko Z. <he...@zu...>]

>>> Yeah, that would be too much work.  If we decided to go this route,
>>> we could keep it simple by changing server packages to only run from
>>> the hard drive (CD is not even an option).  But I'm not sure how many
>>> people would complain that's not secure enough.
>>
>> I would complain. ;-)
>>
>
> There's always one in the crowd ...  :-)

I'm just glad that I have a loud enough voice here. ;-)
Let's not remove the option for including stuff on the CD.

We should also take this opportunity to make sure our install script
support both ways, without adding to much overhead. Something like
installing into a temporary location and a generic script copies all the
stuff into the right place, depending on the configuraton options.


-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] Idea for 1.3 ...

[Bruce S. <bw...@ar...>]

> >Yeah, that would be too much work.  If we decided to go this route, we
> >could keep it simple by changing server packages to only run from the
> >hard drive (CD is not even an option).  But I'm not sure how many people
> >would complain that's not secure enough.
> 
> I would complain. ;-)

There's always one in the crowd ...  :-)

 - BS

Re: [Devil-linux-develop] Idea for 1.3 ...

[Heiko Z. <he...@zu...>]

Bruce Smith wrote:

>>It actually sounds pretty straight forward.
>>I'm a little afraid of how many  DL version we would have to release.
>>
>>Some people would prefer having everything on their CD because it's more 
>>secure, others would like the package option....
>>    
>>
>
>Yeah, that would be too much work.  If we decided to go this route, we
>could keep it simple by changing server packages to only run from the
>hard drive (CD is not even an option).  But I'm not sure how many people
>would complain that's not secure enough.
>  
>

I would complain. ;-)

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] Idea for 1.3 ...

[Bruce S. <bw...@ar...>]

> It actually sounds pretty straight forward.
> I'm a little afraid of how many  DL version we would have to release.
> 
> Some people would prefer having everything on their CD because it's more 
> secure, others would like the package option....

Yeah, that would be too much work.  If we decided to go this route, we
could keep it simple by changing server packages to only run from the
hard drive (CD is not even an option).  But I'm not sure how many people
would complain that's not secure enough.

 - BS

Re: [Devil-linux-develop] Idea for DL: UML

[Bruce S. <bw...@ar...>]

> >during reading the last german c't magazin I got a idea:
> >what about adding UserModeLinux to DL?
> >Some of the users may be use DL also for some services to the internal net.
> >So adding UML would may be allow to save some hardware or bring in a 
> >additional step of security.
> >The idea is to have the UML kernel working only for firewalling (the normal 
> >kernel works only as ethernet bridge to outside network) and may be ppp.
> >All other things running as services on the normal kernel, so there is some 
> >kind of DMZ in one hardware box.
> >May be I miss it and this is already possible today?
> >What do you think?
> 
> The idea in general is not bad. There's also another project out there, 
> which does Virtualization under Linux (similar to VMWare).

Has anyone got UML to work, on any system?  (I haven't)

I tried it on SuSE 9.2, which has all the UML RPM's and a GUI setup in
YAST and it hung up part way into the install of the UML system.

 - BS

Re: [Devil-linux-develop] Idea for DL: UML

[Heiko Z. <he...@zu...>]

Frank Pieczynski wrote:

>Hello,
>during reading the last german c't magazin I got a idea:
>what about adding UserModeLinux to DL?
>Some of the users may be use DL also for some services to the internal net.
>So adding UML would may be allow to save some hardware or bring in a 
>additional step of security.
>The idea is to have the UML kernel working only for firewalling (the normal 
>kernel works only as ethernet bridge to outside network) and may be ppp.
>All other things running as services on the normal kernel, so there is some 
>kind of DMZ in one hardware box.
>May be I miss it and this is already possible today?
>What do you think?
>
>  
>

The idea in general is not bad. There's also another project out there, 
which does Virtualization under Linux (similar to VMWare).

One question which comes to my mind is, does the UML Kernel work with 
grsecurity ? If not, then you would have an un-protected system which is 
actually worse then running everything on the main system.

I think it would be much better if people would start writing chroot 
configs for DL. The framework we provide makes this quite easy, it just 
takes somebody to do it.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

[Devil-linux-develop] Idea for DL: UML

[Frank P. <pi...@we...>]

Hello,
during reading the last german c't magazin I got a idea:
what about adding UserModeLinux to DL?
Some of the users may be use DL also for some services to the internal net.
So adding UML would may be allow to save some hardware or bring in a 
additional step of security.
The idea is to have the UML kernel working only for firewalling (the normal 
kernel works only as ethernet bridge to outside network) and may be ppp.
All other things running as services on the normal kernel, so there is some 
kind of DMZ in one hardware box.
May be I miss it and this is already possible today?
What do you think?
Regards
Frank

Re: [Devil-linux-develop] Idea for 1.3 ...

[Heiko Z. <he...@zu...>]

MickeyByte wrote:

>>It actually sounds pretty straight forward.
>>I'm a little afraid of how many  DL version we would have to release.
>>
>>Some people would prefer having everything on their CD because it's more
>>secure, others would like the package option....
>>
>>    
>>
>
>Hi,
>
>I think that's indead a great idea.
>Concerning the different DL versions, another solution is possible.
>Here's what I have in mind:
>You make a basic DL version including all necessary utilities that a
>firewall nowadays has.
>  
>
That's always a problem to define those.
But we could say, everything which doesn't need a harddisk.
But I think we would stiil need to provide a everything-on-CD version.

>Apart from that, you could put additional packages on the website,
>including the modified installation scripts for DL. Then, if anyone
>wants to use for exampel Apache on his firewall, he could download the
>package from the website, put it in a directory on the firewall (eg
>/var/opt/packages) en start the install script.
>Maybe you can then also change the UI for services that exists now, to
>check what packages are in that directory en built up the list
>dynamically and also install them from there. Or you could even
>retrieve a list of available packages from the web, and even download
>and install them automatically (oops, better get my feet back on the
>ground!)
>
>It's just an idea, I'm not a developper, so I have no idea if it's
>technical possible (well, sure it is, but...)
>  
>

It's actually all do-able, but it could turn into a security and/or 
maintenance nightmare.
Don't forgett that we currently only have 2 active Core-Developers.

-- 

Regards
  Heiko Zuerker
  http://www.devil-linux.org

Re: [Devil-linux-develop] Idea for 1.3 ...

[MickeyByte <mic...@gm...>]

> It actually sounds pretty straight forward.
> I'm a little afraid of how many  DL version we would have to release.
> 
> Some people would prefer having everything on their CD because it's more
> secure, others would like the package option....
> 

Hi,

I think that's indead a great idea.
Concerning the different DL versions, another solution is possible.
Here's what I have in mind:
You make a basic DL version including all necessary utilities that a
firewall nowadays has.
Apart from that, you could put additional packages on the website,
including the modified installation scripts for DL. Then, if anyone
wants to use for exampel Apache on his firewall, he could download the
package from the website, put it in a directory on the firewall (eg
/var/opt/packages) en start the install script.
Maybe you can then also change the UI for services that exists now, to
check what packages are in that directory en built up the list
dynamically and also install them from there. Or you could even
retrieve a list of available packages from the web, and even download
and install them automatically (oops, better get my feet back on the
ground!)

It's just an idea, I'm not a developper, so I have no idea if it's
technical possible (well, sure it is, but...)

Regards,
Michiel Peene