Menu
▾
▴
devil-linux-develop — developer discussions
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(55) |
Oct
(44) |
Nov
(156) |
Dec
(123) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(130) |
Feb
(156) |
Mar
(162) |
Apr
(171) |
May
(97) |
Jun
(127) |
Jul
(58) |
Aug
(81) |
Sep
(86) |
Oct
(45) |
Nov
(41) |
Dec
(84) |
| 2003 |
Jan
(71) |
Feb
(87) |
Mar
(133) |
Apr
(152) |
May
(151) |
Jun
(232) |
Jul
(320) |
Aug
(237) |
Sep
(271) |
Oct
(536) |
Nov
(301) |
Dec
(393) |
| 2004 |
Jan
(393) |
Feb
(184) |
Mar
(314) |
Apr
(225) |
May
(139) |
Jun
(77) |
Jul
(87) |
Aug
(75) |
Sep
(139) |
Oct
(50) |
Nov
(8) |
Dec
(28) |
| 2005 |
Jan
(66) |
Feb
(63) |
Mar
(14) |
Apr
(14) |
May
(8) |
Jun
(23) |
Jul
(21) |
Aug
(6) |
Sep
(29) |
Oct
(55) |
Nov
(38) |
Dec
(8) |
| 2006 |
Jan
(5) |
Feb
(10) |
Mar
(1) |
Apr
(15) |
May
(32) |
Jun
(44) |
Jul
(11) |
Aug
(8) |
Sep
(9) |
Oct
(14) |
Nov
(4) |
Dec
(3) |
| 2007 |
Jan
(3) |
Feb
(3) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(35) |
Aug
(49) |
Sep
(8) |
Oct
(42) |
Nov
(44) |
Dec
(7) |
| 2008 |
Jan
(2) |
Feb
(7) |
Mar
(8) |
Apr
(80) |
May
(74) |
Jun
(29) |
Jul
(5) |
Aug
(7) |
Sep
(6) |
Oct
(1) |
Nov
|
Dec
|
| 2009 |
Jan
(8) |
Feb
(19) |
Mar
(3) |
Apr
(24) |
May
(22) |
Jun
(23) |
Jul
(8) |
Aug
(23) |
Sep
(8) |
Oct
(27) |
Nov
(52) |
Dec
(27) |
| 2010 |
Jan
(36) |
Feb
(29) |
Mar
(17) |
Apr
(28) |
May
(21) |
Jun
(4) |
Jul
|
Aug
(28) |
Sep
(18) |
Oct
(6) |
Nov
(34) |
Dec
(16) |
| 2011 |
Jan
(18) |
Feb
(12) |
Mar
|
Apr
|
May
(9) |
Jun
(1) |
Jul
(5) |
Aug
(5) |
Sep
(7) |
Oct
(16) |
Nov
(26) |
Dec
(17) |
| 2012 |
Jan
(6) |
Feb
(34) |
Mar
(52) |
Apr
(10) |
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
(4) |
Nov
(1) |
Dec
(4) |
| 2013 |
Jan
(5) |
Feb
|
Mar
|
Apr
(5) |
May
(4) |
Jun
|
Jul
|
Aug
(14) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
|
Feb
(2) |
Mar
(5) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(11) |
| 2015 |
Jan
(5) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
(1) |
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Heiko Z. <hz...@pr...> - 2003-10-16 17:20:22
|
On 10/16/2003 09:02:47 AM Bruce Smith wrote: >> the new build system seems to work now. >> I just finished a full compile including new lfssystem without any >> problems. >> >> Please start testing. > >LATE last night (near the end of the Cubs game): >I updated from CVS and updated source (after fixing ftp permissions :)= >installed a new lfssystem and started a compile. I'm still up to date= >as of this morning (no new updates since then). Yesterday NOT SO LATE (far away from the end of the Cubs game (I think)= ) I wrote an Email to the Mailinglist that you should not select PHP, bec= ause it's not finished yet. But it seems like it never left my mail server. :-(( But it's good that you got that far, that means (almost) everything wor= ks ! You got 2 options: 1) de-select PHP 2) fix the PHP install script ( I prefer this one ! ) cya Heiko = |
|
From: Thomas E. <tho...@bu...> - 2003-10-16 17:17:13
|
Friedrich Lobenstock wrote: > I think we have to make up or minds about what Devil-Linux should > really be. At the moment it is some kind of "everything-and-nothing", > more like Knoppix but just for servers, not for desktops. > > I'd really like to have a Devil Linux Firewall Edition that I would > use on my firewall. > > So what are all the other people on this list thinking about how > Devil-Linux should proceed in the future? > I think there should be different ISOs. -- thomas |
|
From: Dean N. <di...@ti...> - 2003-10-16 16:22:52
|
I get up a little late, and look at all of the discussion I miss! >>Bruce Smith wrote: >> General question (not necessarily directed toward UPnP): >> >> Do we need to start getting picky about what software is included? >> >> One of these days in the not so distant future, the DL ISO is going to >> become too large to fit on a single CD. In my experience it's much >> easier to reject software requests now, as opposed to removing software >> later to reduce the size. (at least we won't piss off people as much :) >> >> Or maybe we don't worry about it, and when DL doesn't fit on a CD any >> longer we start building different ISO's? (firewall edition, mail >> server edition, web server edition, ... stupid software edition :) > >As it is now I think the only way is to create different ISOs >as we already have stuff that should no be on a firewall but >are perfectly fine on some intranet server. > >> Or maybe DL goes DVD-only after it surpasses the 650/700MB limit? > >Looks like we are currently heading in this direction. While I am concerned about the amount of software that we keep adding, I will point out (probably to my detriment) that other distros (like Knoppix) do a compressed ISO image - and that is how they fit over 2 Gigabytes on a 650MB CD. >> As I said, I'm not picking on UPnP. I haven't read about it yet, and >> don't really understand what it is. This is just something I've been >> wondering about for awhile ... > >I think we have to make up or minds about what Devil-Linux should >really be. At the moment it is some kind of "everything-and-nothing", >more like Knoppix but just for servers, not for desktops. > To be honest, when I started using Devil-Linux - I thought I was getting a stripped down, securely built, grsecurity enhanced firewall. >I'd really like to have a Devil Linux Firewall Edition that I would >use on my firewall. I STRONGLY support that. Of course, whether we could agree on what needs to be on it... (IPTables, DHCP client, and Postfix would suit my needs - unless I can get ClamAV and SAGATOR to work as well). >So what are all the other people on this list thinking about how >Devil-Linux should proceed in the future? As a thought - maybe in addition to the build system, we could develop a tool to create the ISO image from a .bz2 file (or multiple .bz2 files) based on a menu. I.e, I go into a menu, select IPTables, DHCP client, and Postfix and the program/script creates a temporary directory, unpacks the "Devil-Linux" core bz2 file, unpacks the DHCP client bz2 file and merges it into the temporary directory, unpacks and merges the Postfix bz2 file, and then creates an ISO image out of the whole thing. This is different in how we do things now in that I am not suggesting that anything needs to be recompiled - just assembled. As we talk about this, lets consider the extreme case - the gentleman who is trying to run Devil-linux over at the web cafe. We have gotten several feature requests from him (L7 rate shaping, UPnP, etc.) that would probably never fit into a standard "profile". So, instead, we need to give him an easy way to create his own ISO file (and I am suggesting that the current system of compiling everything isn't an easy way). Dean Nedelman TimeLord Consulting |
|
From: Heiko Z. <hz...@pr...> - 2003-10-16 15:17:39
|
On 10/16/2003 10:47:37 AM Bruce Smith wrote: >> >Let me say first that I'm NOT in favor of a DVD distro, which leave= s >us >> >with two other options (as far as I can tell): >> > >> >1) Get tough and start rejecting software requests. >> > >> >2) Keep accepting all/most reasonable requests and plan on creatin= g >> >multiple editions (ISO's) sometime in the future. >> > >> >I'm actually leaning toward #2. If we go with #1 and don't accept >> >another software request ever again, we'll still run out of room >someday >> >because existing packages will continue growing in size. >> >> I agree with 2, too. ;-) > >Yeah. I'd only agree with #1 if I get what *I* want included! ;-) Same here. ;-) >Speaking of adding crap, how about "gpm"? >Sometimes it'd be nice to be able to copy/paste stuff with a mouse. >And it'd be easier for users to send exact error messages to us! :-) Why not.... >> We were talking about this earlier, it should be fairly easy to add >> profiles to our menuconfig. > >Deciding what to put in the profiles will be the difficult thing. >Everyone will want a different combination, like the recent poster >who's running Samba on his firewall because money is tight ... >(not picking on him, I just see Samba being in a different profile >that the firewall stuff) I would say we do it base on our best judgment. If a user really doesn't like how we selected it: get the build system = and create your own version. cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-16 14:47:51
|
> >Let me say first that I'm NOT in favor of a DVD distro, which leaves us > >with two other options (as far as I can tell): > > > >1) Get tough and start rejecting software requests. > > > >2) Keep accepting all/most reasonable requests and plan on creating > >multiple editions (ISO's) sometime in the future. > > > >I'm actually leaning toward #2. If we go with #1 and don't accept > >another software request ever again, we'll still run out of room someday > >because existing packages will continue growing in size. > > I agree with 2, too. ;-) Yeah. I'd only agree with #1 if I get what *I* want included! ;-) Speaking of adding crap, how about "gpm"? Sometimes it'd be nice to be able to copy/paste stuff with a mouse. And it'd be easier for users to send exact error messages to us! :-) > We were talking about this earlier, it should be fairly easy to add > profiles to our menuconfig. Deciding what to put in the profiles will be the difficult thing. Everyone will want a different combination, like the recent poster who's running Samba on his firewall because money is tight ... (not picking on him, I just see Samba being in a different profile that the firewall stuff) - BS |
|
From: Bruce S. <bw...@ar...> - 2003-10-16 14:37:01
|
Must have missed that one ... (can I blame it on sf.net's mailing lists? :) - BS > ok here it is again: > > > Hey, > > > > I just checked in PHP and a bunch of dependiencies for it. > > PHP doesn't install yet and a few more libraries have to be added, so > > don't select it in menuconfig. > > Of courses... if you want to fix all the stuff : go ahead! ;-) > > > > cya > > Heiko |
|
From: Heiko Z. <hz...@pr...> - 2003-10-16 14:31:18
|
On 10/16/2003 09:59:34 AM Friedrich Lobenstock wrote: >Friedrich Lobenstock wrote: >> I think we have to make up or minds about what Devil-Linux should >> really be. At the moment it is some kind of "everything-and-nothing"= , >> more like Knoppix but just for servers, not for desktops. > >A new name comes to my mind Devilix. *LOL* >Just joking ;-) It's a good one, you got a good laugh out of me. ;-) cya Heiko = |
|
From: Heiko Z. <hz...@pr...> - 2003-10-16 14:23:51
|
On 10/16/2003 09:57:07 AM Bruce Smith wrote: >> >One of these days in the not so distant future, the DL ISO is going= >to >> >become too large to fit on a single CD. In my experience it's much= >> >easier to reject software requests now, as opposed to removing >software >> >later to reduce the size. (at least we won't piss off people as muc= h >:) >> > >> >Or maybe we don't worry about it, and when DL doesn't fit on a CD a= ny >> >longer we start building different ISO's? (firewall edition, mail >> >server edition, web server edition, ... stupid software edition :) >> > >> >Or maybe DL goes DVD-only after it surpasses the 650/700MB limit? >> >> It's a very good point. > >I'm afraid it'll happen soon. Especially if we keep adding everything= >that is requested. Everybody is going to want something different. > >> I'm not sure how we should handle it. >> It's sometimes hard to decide if we really need a specific software.= > >Let me say first that I'm NOT in favor of a DVD distro, which leaves u= s >with two other options (as far as I can tell): > >1) Get tough and start rejecting software requests. > >2) Keep accepting all/most reasonable requests and plan on creating >multiple editions (ISO's) sometime in the future. > >I'm actually leaning toward #2. If we go with #1 and don't accept >another software request ever again, we'll still run out of room somed= ay >because existing packages will continue growing in size. I agree with 2, too. ;-) We were talking about this earlier, it should be fairly easy to add profiles to our menuconfig. cya Heiko = |
|
From: Heiko Z. <hz...@pr...> - 2003-10-16 14:21:07
|
ok here it is again: > Hey, > > I just checked in PHP and a bunch of dependiencies for it. > PHP doesn't install yet and a few more libraries have to be added, so= > don't select it in menuconfig. > Of courses... if you want to fix all the stuff : go ahead! ;-) > > cya > Heiko > = |
|
From: Friedrich L. <fl...@fl...> - 2003-10-16 14:01:57
|
Friedrich Lobenstock wrote: > I think we have to make up or minds about what Devil-Linux should > really be. At the moment it is some kind of "everything-and-nothing", > more like Knoppix but just for servers, not for desktops. A new name comes to my mind Devilix. Just joking ;-) -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Bruce S. <bw...@ar...> - 2003-10-16 13:57:09
|
> >One of these days in the not so distant future, the DL ISO is going to
> >become too large to fit on a single CD. In my experience it's much
> >easier to reject software requests now, as opposed to removing software
> >later to reduce the size. (at least we won't piss off people as much :)
> >
> >Or maybe we don't worry about it, and when DL doesn't fit on a CD any
> >longer we start building different ISO's? (firewall edition, mail
> >server edition, web server edition, ... stupid software edition :)
> >
> >Or maybe DL goes DVD-only after it surpasses the 650/700MB limit?
>
> It's a very good point.
I'm afraid it'll happen soon. Especially if we keep adding everything
that is requested. Everybody is going to want something different.
> I'm not sure how we should handle it.
> It's sometimes hard to decide if we really need a specific software.
Let me say first that I'm NOT in favor of a DVD distro, which leaves us
with two other options (as far as I can tell):
1) Get tough and start rejecting software requests.
2) Keep accepting all/most reasonable requests and plan on creating
multiple editions (ISO's) sometime in the future.
I'm actually leaning toward #2. If we go with #1 and don't accept
another software request ever again, we'll still run out of room someday
because existing packages will continue growing in size.
FWIW ... :-)
- BS
|
|
From: Friedrich L. <fl...@fl...> - 2003-10-16 13:53:08
|
Bruce Smith wrote: > General question (not necessarily directed toward UPnP): > > Do we need to start getting picky about what software is included? > > One of these days in the not so distant future, the DL ISO is going to > become too large to fit on a single CD. In my experience it's much > easier to reject software requests now, as opposed to removing software > later to reduce the size. (at least we won't piss off people as much :) > > Or maybe we don't worry about it, and when DL doesn't fit on a CD any > longer we start building different ISO's? (firewall edition, mail > server edition, web server edition, ... stupid software edition :) As it is now I think the only way is to create different ISOs as we already have stuff that should no be on a firewall but are perfectly fine on some intranet server. > Or maybe DL goes DVD-only after it surpasses the 650/700MB limit? Looks like we are currently heading in this direction. > As I said, I'm not picking on UPnP. I haven't read about it yet, and > don't really understand what it is. This is just something I've been > wondering about for awhile ... I think we have to make up or minds about what Devil-Linux should really be. At the moment it is some kind of "everything-and-nothing", more like Knoppix but just for servers, not for desktops. I'd really like to have a Devil Linux Firewall Edition that I would use on my firewall. So what are all the other people on this list thinking about how Devil-Linux should proceed in the future? -- MfG / Regards Friedrich Lobenstock ____________________________________________________________________ Friedrich Lobenstock Linux Services Lobenstock URL: http://www.lsl.at/ Email: fl...@fl... ____________________________________________________________________ |
|
From: Heiko Z. <hz...@pr...> - 2003-10-16 13:43:42
|
On 10/16/2003 09:18:26 AM Bruce Smith wrote: >General question (not necessarily directed toward UPnP): > >Do we need to start getting picky about what software is included? > >One of these days in the not so distant future, the DL ISO is going to= >become too large to fit on a single CD. In my experience it's much >easier to reject software requests now, as opposed to removing softwar= e >later to reduce the size. (at least we won't piss off people as much := ) > >Or maybe we don't worry about it, and when DL doesn't fit on a CD any >longer we start building different ISO's? (firewall edition, mail >server edition, web server edition, ... stupid software edition :) > >Or maybe DL goes DVD-only after it surpasses the 650/700MB limit? > >As I said, I'm not picking on UPnP. I haven't read about it yet, and >don't really understand what it is. This is just something I've been >wondering about for awhile ... It's a very good point. I'm not sure how we should handle it. It's sometimes hard to decide if we really need a specific software. cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-16 13:20:45
|
General question (not necessarily directed toward UPnP): Do we need to start getting picky about what software is included? One of these days in the not so distant future, the DL ISO is going to become too large to fit on a single CD. In my experience it's much easier to reject software requests now, as opposed to removing software later to reduce the size. (at least we won't piss off people as much :) Or maybe we don't worry about it, and when DL doesn't fit on a CD any longer we start building different ISO's? (firewall edition, mail server edition, web server edition, ... stupid software edition :) Or maybe DL goes DVD-only after it surpasses the 650/700MB limit? As I said, I'm not picking on UPnP. I haven't read about it yet, and don't really understand what it is. This is just something I've been wondering about for awhile ... - BS |
|
From: Bruce S. <bw...@ar...> - 2003-10-16 13:06:21
|
> the new build system seems to work now. > I just finished a full compile including new lfssystem without any > problems. > > Please start testing. LATE last night (near the end of the Cubs game): I updated from CVS and updated source (after fixing ftp permissions :) installed a new lfssystem and started a compile. I'm still up to date as of this morning (no new updates since then). /etc/apache2/build/libtool --mode=install cp libphp4.la /data/build/tmp/tmp/usr/lib/apache2/modules/ cp .libs/libphp4.so /data/build/tmp/tmp/usr/lib/apache2/modules/libphp4.so cp .libs/libphp4.lai /data/build/tmp/tmp/usr/lib/apache2/modules/libphp4.la libtool: install: warning: remember to run `libtool --finish /data/build/tmp/php-4.3.4RC1/libs' chmod 755 /data/build/tmp/tmp/usr/lib/apache2/modules/libphp4.so [activating module `php4' in /data/build/tmp/tmp/etc/apache2/httpd.conf] Installing shared extensions: /data/build/tmp/tmp/usr/lib/php/extensions/no-debug-non-zts-20020429/ Installing PEAR environment: /data/build/tmp/tmp/usr/lib/php/ make[2]: Entering directory `/data/build/tmp/php-4.3.4RC1' [PEAR] Archive_Tar - installed: 1.1 [PEAR] Console_Getopt - installed: 1.0 [PEAR] PEAR - installed: 1.3b1 Wrote PEAR system config file at: /data/build/tmp/tmp//etc/pear.conf You may want to add: /usr/lib/php to your php.ini include_path [PEAR] DB - installed: 1.5.0RC2 [PEAR] HTTP - installed: 1.2.1 [PEAR] Mail - installed: 1.1.1 [PEAR] Net_SMTP - installed: 1.2.3 [PEAR] Net_Socket - installed: 1.0.1 [PEAR] XML_Parser - installed: 1.0.1 [PEAR] XML_RPC - installed: 1.0.4 make[2]: Leaving directory `/data/build/tmp/php-4.3.4RC1' Installing build environment: /data/build/tmp/tmp/usr/lib/php/build/ Installing header files: /data/build/tmp/tmp/usr/include/php/ Installing helper programs: /data/build/tmp/tmp/usr/bin/ program: phpize program: php-config program: phpextdist make[1]: Leaving directory `/data/build/tmp/php-4.3.4RC1' ERROR /data/build/scripts/php install failed make: *** [install] Error 1 |
|
From: SourceForge.net <no...@so...> - 2003-10-16 12:53:33
|
Feature Requests item #824804, was opened at 2003-10-16 07:53 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410646&aid=824804&group_id=34096 Category: Packages Group: None Status: Open Priority: 5 Submitted By: Heiko Zuerker (smiley73) Assigned to: Nobody/Anonymous (nobody) Summary: add UPnP support Initial Comment: http://linux-igd.sourceforge.net/ ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410646&aid=824804&group_id=34096 |
|
From: <no...@fr...> - 2003-10-16 08:46:27
|
This email is to inform you about the release of version '4.06' of 'file' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/file/ The changes in this release are as follows: Python bindings were added. Some of the magic definitions were fixed along with several minor bugs. Project description: File attempts to classify files depending on their contents and prints a description if a match is found. If you would like to cancel subscription to releases of this project, login to freshmeat.net and choose 'home' from the personal menubar at the top of the page. You'll be presented with a list of projects you're subscribed to in the right column, which you may cancel by highlighting the project in question and clicking the 'delete' button. Sincerely, freshmeat.net ____________________________| Advertising |____________________________ Got the debugger blues? Try Etnus TotalView, the Best Linux/UNIX debugger on the planet. With superior C++ support, the best thread debugging available, a great GUI, and more useful features than any other debugger, TotalView helps reveal bugs faster than any other debugger. And it provides more insight and analysis about your code and your data. So cure the debugger blues. Get your free 15-day trial at http://www.etnus.com/Download/demo-tv.html ____________________________| Advertising |____________________________ |
|
From: SourceForge.net <no...@so...> - 2003-10-15 23:49:47
|
Bugs item #823587, was opened at 2003-10-14 12:28 Message generated for change (Settings changed) made by smiley73 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410643&aid=823587&group_id=34096 Category: Documentation Group: None >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Heiko Zuerker (smiley73) >Assigned to: Heiko Zuerker (smiley73) Summary: add information about cvs branches Initial Comment: I would suggest that you use the 1.0 version, since the 1.1 build system is undergoing major changes right now and is right now hard to support/debug in such an early stage. Specify "-r rel-1-0-patches" when you do a checkout from the CVS. Using 1.1 only makes sense when you do active development. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=410643&aid=823587&group_id=34096 |
|
From: Heiko Z. <hz...@pr...> - 2003-10-15 20:14:05
|
Hey, the new build system seems to work now. I just finished a full compile including new lfssystem without any problems. Please start testing. cya Heiko = |
|
From: <no...@fr...> - 2003-10-15 19:41:53
|
This email is to inform you about the release of version '2.1.16-BETA' of 'Cyrus SASL' through freshmeat.net. All URLs and other useful information can be found at http://freshmeat.net/projects/cyrussasl/ The changes in this release are as follows: This release contains significant changes in a variety of areas, including PostgreSQL support for the SQL auxilliary property plugin, Win32 support, writable auxiliary property support, and the use of newer versions of the GNU autotools. Project description: The Cyrus SASL library is a generic library for easy integration of secure network authentication to any client or server application. It supports authentication via standard plaintext methods as well as CRAM-MD5 and DIGEST-MD5 shared secret methods and KERBEROS_V4 and GSSAPI Kerberos methods. The SASL protocol framework is used by SMTP, IMAP, ACAP, LDAP, and other standard protocols. If you would like to cancel subscription to releases of this project, login to freshmeat.net and choose 'home' from the personal menubar at the top of the page. You'll be presented with a list of projects you're subscribed to in the right column, which you may cancel by highlighting the project in question and clicking the 'delete' button. Sincerely, freshmeat.net ____________________________| Advertising |____________________________ Got the debugger blues? Try Etnus TotalView, the Best Linux/UNIX debugger on the planet. With superior C++ support, the best thread debugging available, a great GUI, and more useful features than any other debugger, TotalView helps reveal bugs faster than any other debugger. And it provides more insight and analysis about your code and your data. So cure the debugger blues. Get your free 15-day trial at http://www.etnus.com/Download/demo-tv.html ____________________________| Advertising |____________________________ |
|
From: Heiko Z. <hz...@pr...> - 2003-10-15 13:26:29
|
On 10/15/2003 09:10:22 AM Bruce Smith wrote: >> I extracted the patch from the Redhat Kernel src.rpm, but didn't hav= e >time >> to give it a try yet. >> Any suggestion how we should implement this? >> Should we lock i.e. 5 minutes (configurable) after the bootup? >> Should we lock immediately (configurable)? > >Or we could do both. >Lock (or not, configurable) after "n" minutes (also configurable). LOCK_MODULE_LOADING=3D"0" immediately after booting the system LOCK_MODULE_LOADING=3D"5" after 5 minutes (default ?) LOCK_MODULE_LOADING=3D"n" don't do it cya Heiko = |
|
From: Bruce S. <bw...@ar...> - 2003-10-15 13:16:06
|
> >Shall I replace the loadlin.exe binary and tar up my own package and > >name it loadlin16c.tar.bz2 ? > > Name it loadlin16-devil.tar.bz2 , so we don't wonder in a couple of > month... I named it loadlin16c-devil.tar.bz2, PLUS I added a Devil-Linux.txt file in the package telling what I did. I'll be uploading shortly ... - BS |
|
From: Bruce S. <bw...@ar...> - 2003-10-15 13:10:24
|
> I extracted the patch from the Redhat Kernel src.rpm, but didn't have time > to give it a try yet. > Any suggestion how we should implement this? > Should we lock i.e. 5 minutes (configurable) after the bootup? > Should we lock immediately (configurable)? Or we could do both. Lock (or not, configurable) after "n" minutes (also configurable). - BS > For the setup of the computer we need to be able to still load modules. > cya > Heiko > > On 10/14/2003 02:23:32 PM "Dean Nedelman" wrote: > >Well, from what I could find, does this make any sense to you? > >linux-2.4.20-modulesoff.patch > > > >The only place besides RedHat that I could find it mentioned was on the > >SentryFirewall site. So it may be a RedHat specific modification. In > >particular, I couldn't find it mentioned on the Kernel mailing list > >archives... > > > >Dean > > > >-----Original Message----- > >Subject: Re: [Devil-linux-develop] Feature Request: Disabling of Module > >Loading > > > > > >I really like that idea ! > >Can you find out which Kernel Patch is providing this feature? > > > >Heiko > > > >On 10/13/2003 11:08:32 PM "Dean Nedelman" wrote: > >>I was reading the release notes for Fedora (the latest version of > >>RedHat's > >>consumer product - in beta). It had the following comment > >>(http://fedora.redhat.com/docs/release-notes/): > >> > >>------------------ > >> > >>The Fedora Core 0.94 kernel now makes it possible to prevent the > >>loading of > >>kernel modules. This can be useful for system administrators wanting to > >>ensure that only a strictly-controlled set of modules are loaded. To > >>disable > >>kernel module loading, issue the following command: > >> > >>echo off > /proc/modules > >> > >>Once this command has been issued, all further attempts to load kernel > >>modules will fail. > >> > >>NOTE: Once kernel module loading has been disabled, a reboot is > >>required to > >>re-enable it. > >> > >>------------------------ > >> > >>And I was thinking - wouldn't this be a useful feature for Devil-Linux? > >>After all - we are [presumably] running a "static" environment. So > >>once a > >>system is booted, wouldn't we WANT to prevent the loading (and/or > >>changing) > >>of kernel modules? |
|
From: Heiko Z. <hz...@pr...> - 2003-10-15 12:55:45
|
Hey, I extracted the patch from the Redhat Kernel src.rpm, but didn't have t= ime to give it a try yet. Any suggestion how we should implement this? Should we lock i.e. 5 minutes (configurable) after the bootup? Should we lock immediately (configurable)? For the setup of the computer we need to be able to still load modules.= cya Heiko On 10/14/2003 02:23:32 PM "Dean Nedelman" wrote: >Well, from what I could find, does this make any sense to you? >linux-2.4.20-modulesoff.patch > >The only place besides RedHat that I could find it mentioned was on th= e >SentryFirewall site. So it may be a RedHat specific modification. In= >particular, I couldn't find it mentioned on the Kernel mailing list >archives... > >Dean > >-----Original Message----- >Subject: Re: [Devil-linux-develop] Feature Request: Disabling of Modul= e >Loading > > >I really like that idea ! >Can you find out which Kernel Patch is providing this feature? > >Heiko > >On 10/13/2003 11:08:32 PM "Dean Nedelman" wrote: >>I was reading the release notes for Fedora (the latest version of >>RedHat's >>consumer product - in beta). It had the following comment >>(http://fedora.redhat.com/docs/release-notes/): >> >>------------------ >> >>The Fedora Core 0.94 kernel now makes it possible to prevent the >>loading of >>kernel modules. This can be useful for system administrators wanting = to >>ensure that only a strictly-controlled set of modules are loaded. To >>disable >>kernel module loading, issue the following command: >> >>echo off > /proc/modules >> >>Once this command has been issued, all further attempts to load kerne= l >>modules will fail. >> >>NOTE: Once kernel module loading has been disabled, a reboot is >>required to >>re-enable it. >> >>------------------------ >> >>And I was thinking - wouldn't this be a useful feature for Devil-Linu= x? >>After all - we are [presumably] running a "static" environment. So >>once a >>system is booted, wouldn't we WANT to prevent the loading (and/or >>changing) >>of kernel modules? > > > >------------------------------------------------------- >This SF.net email is sponsored by: SF.net Giveback Program. >SourceForge.net hosts over 70,000 Open Source Projects. >See the people who have HELPED US provide better services: >Click here: http://sourceforge.net/supporters.php >_______________________________________________ >Devil-linux-develop mailing list >Dev...@li... >https://lists.sourceforge.net/lists/listinfo/devil-linux-develop = |
|
From: Heiko Z. <hz...@pr...> - 2003-10-15 12:52:26
|
On 10/15/2003 08:25:43 AM Bruce Smith wrote: >> >> So, I copied loadlin.exe (16c) to my floppy, and ran it from ther= e. >> >> Boots fine! :-) >> >> >> >> BTW, the linux.bat kernel parameters probably need to be updated >too, >> >> since they don't match the parameters in isolinux.cfg. >> >> >> >> Is this a bug fix for 1.0, or a new 1.1 feature? ;-> >> > >> > As it fixes a problem it is definitely a bug fix, I'd say. >> > >> Agreed. > >Wow, an actual bug for 1.0 ... :-) No. Actually a bug in <=3D 1.0-RC2 ;-) >> RC2 is already uploaded, so it will go into RC3 then. > >What's the best way to handle this one? > >The current source file is: loadlin16.tar.bz2 >The author doesn't offer a new tar file, only a new loadlin.exe binary= . Do I hate this... But at least there's an update. >Shall I replace the loadlin.exe binary and tar up my own package and >name it loadlin16c.tar.bz2 ? Name it loadlin16-devil.tar.bz2 , so we don't wonder in a couple of month... cya Heiko = |
35 messages has been excluded from this view by a project administrator.
