From: Heiko Z. <he...@zu...> - 2009-05-31 20:55:09
|
Hi everyone, I know it took us quite a while, but the first Release Candidate of Devil-Linux 1.4 is available for download. Some of the new features are Kernel 2.6, Webmin, less space requirement on the config media, lot's of new programs and much much more. Please report any problems on hour mailinglist. -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Dominic R. <dl...@ed...> - 2009-06-04 10:18:11
|
My thanks to Heiko and all the developers for their hard work, we now have 1.4RC1 working well. Webmin is very cool. Note that the default settings for module 'Samba Windows File Sharing' in Webmin assume all key files are in /usr/local/samba/bin which ain't so; once I fix these the module seems to work well. Thinking of newbies, could a new install of DL attempt to autoconfigure eth0 i.e. identify and load an appropriate ethernet module and try to pick up IP from an external DHCP server? I guess using something like kudzu http://linux.die.net/man/8/kudzu. (This would also be necessary if you want in future to offer Webmin 'out of the box' as alternative for text-based Setup.) It seems to me a stumbling block for (some) newcomers to DL that they have to identify the ethernet module manually (i.e. hunt on Google, try it, hunt again...) before network connection is possible; many other Linux distros 'just work'. I would also like to request that rdiff-backup (http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/) be added to the next release? I see you have added Bacula, so it makes sense (IMO) to add another (very powerful) backup tool. 'rdiff-backup backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago.' Apart from rdiff-backup itself the only other missing requirement in DL is librsync v0.9.7. Unfortunately there is a known bug in librsync v0.9.7 affecting large files for which a patch is available at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355178. Dominic Heiko Zuerker wrote: > Hi everyone, > > I know it took us quite a while, but the first Release Candidate of > Devil-Linux 1.4 is available for download. > > Some of the new features are Kernel 2.6, Webmin, less space > requirement on the config media, lot's of new programs and much much > more. > > Please report any problems on hour mailinglist. > > |
From: Serge L. <fi...@in...> - 2009-06-06 05:03:20
|
Hello, Dominic Raferd wrote: > Thinking of newbies, could a new install of DL attempt to autoconfigure > eth0 i.e. identify and load an appropriate ethernet module and try to > pick up IP from an external DHCP server? Actually, udev loads all necessary modules during startup. The field "module" is optional for the simplest cases and allows to define any non-standard options for modules (bonding for example). So, if we put a prepared ifcfg script for eth0 with DHCP configured then the network will start automatically. The question is - do we really need this feature? > > I would also like to request that rdiff-backup > (http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/) be added > to the next release? I see you have added Bacula, so it makes sense > (IMO) to add another (very powerful) backup tool. 'rdiff-backup backs up > one directory to another, possibly over a network. The target directory > ends up a copy of the source directory, but extra reverse diffs are > stored in a special subdirectory of that target directory, so you can > still recover files lost some time ago.' Apart from rdiff-backup itself > the only other missing requirement in DL is librsync v0.9.7. > Unfortunately there is a known bug in librsync v0.9.7 affecting large > files for which a patch is available at > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355178. It's really difficult to make a decision about the package if we know nothing about it. Due to DL nature it's impossible to just create a rpm/deb and allow users to choose to install it or not. DL grows and it may be a problem. I'd leave this question for Heiko - if I find out this feature request in BT assigned to me ;-) I'll know that it's necessary to do :-) Sincerely, Serge |
From: Dominic R. <dl...@ed...> - 2009-06-06 07:16:54
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body bgcolor="#ffffff" text="#000000"> Hello Serge,<br> <br> On 06/06/2009 08:03, Serge Leschinsky wrote: <blockquote cite="mid:4A2...@in..." type="cite"> <pre wrap="">Hello, Dominic Raferd wrote: </pre> <blockquote type="cite"> <pre wrap="">Thinking of newbies, could a new install of DL attempt to autoconfigure eth0 i.e. identify and load an appropriate ethernet module and try to pick up IP from an external DHCP server? </pre> </blockquote> <pre wrap=""><!---->Actually, udev loads all necessary modules during startup. The field "module" is optional for the simplest cases and allows to define any non-standard options for modules (bonding for example). So, if we put a prepared ifcfg script for eth0 with DHCP configured then the network will start automatically. The question is - do we really need this feature? </pre> </blockquote> Thanks for the info re udev. Personally I don't need this feature and I am sure you don't, but anything which helps newcomers seems beneficial IMO. I added the request to the new bug/feature-request tracking tool.<br> <blockquote cite="mid:4A2...@in..." type="cite"> <blockquote type="cite"> <pre wrap="">I would also like to request that rdiff-backup (<a class="moz-txt-link-freetext" href="http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/">http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/</a>) be added to the next release?... </pre> </blockquote> <pre wrap=""><!---->It's really difficult to make a decision about the package if we know nothing about it. Due to DL nature it's impossible to just create a rpm/deb and allow users to choose to install it or not. DL grows and it may be a problem. I'd leave this question for Heiko - if I find out this feature request in BT assigned to me ;-) I'll know that it's necessary to do :-) </pre> </blockquote> rdiff-backup does not take much disk space and does not run as a service (unlike Bacula), so requires no changes to setup, but I accept that once it is in DL it needs to be kept up-to-date which imposes some maintenance burden. Anyway I added it to the bug/feature-list tracker.<br> <br> Regards<br> <br> Dominic<br> </body> </html> |
From: Dick M. <di...@fo...> - 2009-06-06 19:10:27
|
Dominic Refard wrote: >> So, if we put a prepared ifcfg script for eth0 with DHCP configured then the >> network will start automatically. >> >> The question is - do we really need this feature? >> > Thanks for the info re udev. Personally I don't need this feature and I > am sure you don't, but anything which helps newcomers seems beneficial The thing about newbies is that they don't stay newbies for long. DL is not really a general purpose system so it's not particularly helpful to preconfigure things. It's better to have things such that they have to be actively setup before they can be used. That way there are no surprises. If you do need to get help configuring a service there's nothing to stop you copying configs from, say, Debian to use as a basis for your own configuration. >>> I would also like to request that rdiff-backup >>> (http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/) be added >>> to the next release?... It is possible to install apps, particularly script based apps in DL (assuming you have some non volatile storage i.e. hard drive). I put stuff in /opt for example. It usually only becomes a problem if you need a special kernel module. Sometimes you need to do a bit of jiggery-pokery to load a library or something but mostly it's not difficult. There is also the option of rolling your own DL using the development kit. I've not tried this myself but people do. Dick |
From: Heiko Z. <he...@zu...> - 2009-06-06 14:04:01
|
Quoting Serge Leschinsky <fi...@in...>: > Hello, > > Dominic Raferd wrote: > >> Thinking of newbies, could a new install of DL attempt to autoconfigure >> eth0 i.e. identify and load an appropriate ethernet module and try to >> pick up IP from an external DHCP server? > Actually, udev loads all necessary modules during startup. The field > "module" is > optional for the simplest cases and allows to define any non-standard options > for modules (bonding for example). > So, if we put a prepared ifcfg script for eth0 with DHCP configured then the > network will start automatically. > > The question is - do we really need this feature? > >> >> I would also like to request that rdiff-backup >> (http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/) be added >> to the next release? I see you have added Bacula, so it makes sense >> (IMO) to add another (very powerful) backup tool. 'rdiff-backup backs up >> one directory to another, possibly over a network. The target directory >> ends up a copy of the source directory, but extra reverse diffs are >> stored in a special subdirectory of that target directory, so you can >> still recover files lost some time ago.' Apart from rdiff-backup itself >> the only other missing requirement in DL is librsync v0.9.7. >> Unfortunately there is a known bug in librsync v0.9.7 affecting large >> files for which a patch is available at >> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=355178. > > It's really difficult to make a decision about the package if we know nothing > about it. Due to DL nature it's impossible to just create a rpm/deb and allow > users to choose to install it or not. DL grows and it may be a problem. > I'd leave this question for Heiko - if I find out this feature request in BT > assigned to me ;-) I'll know that it's necessary to do :-) What's the big benefit on using this instead of rsync? -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Dominic R. <dl...@ed...> - 2009-06-06 22:35:23
|
On 06/06/2009 17:03, Heiko Zuerker wrote: >> Dominic Raferd wrote: >> I would also like to request that rdiff-backup (http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/) be added to the next release?... >> > What's the big benefit on using this instead of rsync? rsync transfers files in an efficient manner, but it doesn't offer any storage efficiency. Nor, I believe, does Bacula. Quoting: "rdiff-backup backs up one directory to another, possibly over a network. The target directory ends up a copy of the source directory, but extra reverse diffs are stored in a special subdirectory of that target directory, so you can still recover files lost some time ago. The idea is to combine the best features of a mirror and an incremental backup. rdiff-backup also preserves subdirectories, hard links, dev files, permissions, uid/gid ownership, modification times, extended attributes, acls, and resource forks. Also, rdiff-backup can operate in a bandwidth efficient manner over a pipe, like rsync. Thus you can use rdiff-backup and ssh to securely back a hard drive up to a remote location, and only the differences will be transmitted. Finally, rdiff-backup is easy to use and settings have sensical defaults." So if you run it every day (as we do, to a backup server that runs Ubuntu), you have a backup repository which not only has the most recent data (stored in the clear) but also every previous version of every file going back each day since you started. Although this is complicated under the hood, it is easy to use - for backup or restore. I had a case only this week with a corrupted Access 2007 file (a fault in Access 2007 [even SP2] leads to occasional corruption of files); the previous day's backup was corrupt too but I could easily retrieve the file from the day before that - which was fine. Critically, because the data for previous backups is stored in reverse-diff files it is highly space-efficient. So our raw backup data is 80GB, we now have 6 month's worth of daily backups and the backup is 90GB. This includes lots of large database and email files which change daily. I can continue to use Ubuntu for this so I don't feel so strongly, I guess I thought since Bacula had been added to DL it would be logical to add rdiff-backup. Dominic |
From: Bruce S. <bw...@re...> - 2009-06-07 01:07:19
|
> Critically, because the data for previous backups is stored in > reverse-diff files it is highly space-efficient.... How's it work with binary files? (pictures, compiled executables, etc.) - BS |
From: Dominic R. <dl...@ed...> - 2009-06-07 07:43:04
|
On 07/06/2009 03:43, Bruce Smith wrote: >> Critically, because the data for previous backups is stored in >> reverse-diff files it is highly space-efficient.... >> > How's it work with binary files? (pictures, compiled executables, etc.) > For executables it is efficient I believe, for jpegs that change I am not so sure; it cannot be efficient for encrypted files that change (Access .mde or .accde files, for instance). It uses the librsync library to generate the (reverse) diffs i.e. the differences between file versions. Quotes: "librsync implements the rsync remote-delta algorithm" "The algorithm works best when the files are similar, but will also function correctly and reasonably efficiently when the files are quite different" It always stores the most recent version of a file in the clear i.e. uncompressed and unencrypted, so for recovery you only need to use rdiff-backup itself (or a tool based on it) if you need an earlier version of a file (or fileset). There is a similar utility called duplicity (http://duplicity.nongnu.org/) which again uses librsync but stores encrypted tar-format volumes. Because this is inherently more secure it might sort of fit better with the DL philosophy, but it is in beta, and even I don't think DL needs beta software. :-) Dominic |
From: Heiko Z. <he...@zu...> - 2009-06-07 13:59:10
|
Dominic, sounds like a nice little tool. I added a note to the feature request that we'll implement it. There's no ETA, patches are as always welcome. Heiko Quoting Dominic Refard <dl...@ed...>: > On 06/06/2009 17:03, Heiko Zuerker wrote: >>> Dominic Raferd wrote: >>> I would also like to request that rdiff-backup >>> (http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/) be >>> added to the next release?... >>> >> What's the big benefit on using this instead of rsync? > rsync transfers files in an efficient manner, but it doesn't offer any > storage efficiency. Nor, I believe, does Bacula. > > Quoting: "rdiff-backup backs up one directory to another, possibly over > a network. The target directory ends up a copy of the source directory, > but extra reverse diffs are stored in a special subdirectory of that > target directory, so you can still recover files lost some time ago. The > idea is to combine the best features of a mirror and an incremental > backup. rdiff-backup also preserves subdirectories, hard links, dev > files, permissions, uid/gid ownership, modification times, extended > attributes, acls, and resource forks. Also, rdiff-backup can operate in > a bandwidth efficient manner over a pipe, like rsync. Thus you can use > rdiff-backup and ssh to securely back a hard drive up to a remote > location, and only the differences will be transmitted. Finally, > rdiff-backup is easy to use and settings have sensical defaults." > > So if you run it every day (as we do, to a backup server that runs > Ubuntu), you have a backup repository which not only has the most recent > data (stored in the clear) but also every previous version of every file > going back each day since you started. Although this is complicated > under the hood, it is easy to use - for backup or restore. I had a case > only this week with a corrupted Access 2007 file (a fault in Access 2007 > [even SP2] leads to occasional corruption of files); the previous day's > backup was corrupt too but I could easily retrieve the file from the day > before that - which was fine. > > Critically, because the data for previous backups is stored in > reverse-diff files it is highly space-efficient. So our raw backup data > is 80GB, we now have 6 month's worth of daily backups and the backup is > 90GB. This includes lots of large database and email files which change > daily. > > I can continue to use Ubuntu for this so I don't feel so strongly, I > guess I thought since Bacula had been added to DL it would be logical to > add rdiff-backup. > > Dominic > > ------------------------------------------------------------------------------ > OpenSolaris 2009.06 is a cutting edge operating system for enterprises > looking to deploy the next generation of Solaris that includes the latest > innovations from Sun and the OpenSource community. Download a copy and > enjoy capabilities such as Networking, Storage and Virtualization. > Go to: http://p.sf.net/sfu/opensolaris-get > _______________________________________________ > Devil-linux-discuss mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss > -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Dominic R. <dl...@ed...> - 2009-06-08 09:25:46
|
Thanks Heiko, I will look forward to seeing it in the changes list sometime. Sorry I can't help with the patching - way out of my depth! Dominic Heiko Zuerker wrote: > Dominic, > > sounds like a nice little tool. > I added a note to the feature request that we'll implement it. There's > no ETA, patches are as always welcome. > > Heiko > > Quoting Dominic Refard <dl...@ed...>: > > >> On 06/06/2009 17:03, Heiko Zuerker wrote: >> >>>> Dominic Raferd wrote: >>>> I would also like to request that rdiff-backup >>>> (http://www.gnu.org/savannah-checkouts/non-gnu/rdiff-backup/) be >>>> added to the next release?... |
From: Heiko Z. <he...@zu...> - 2009-06-06 14:11:38
|
Quoting Serge Leschinsky <fi...@in...>: > Hello, > > Dominic Raferd wrote: > >> Thinking of newbies, could a new install of DL attempt to autoconfigure >> eth0 i.e. identify and load an appropriate ethernet module and try to >> pick up IP from an external DHCP server? > Actually, udev loads all necessary modules during startup. The field > "module" is > optional for the simplest cases and allows to define any non-standard options > for modules (bonding for example). > So, if we put a prepared ifcfg script for eth0 with DHCP configured then the > network will start automatically. > > The question is - do we really need this feature? One part of the DL philosophy is that nothing happens without the Admin of the Box explicitly allowing it. I'm unsure about this request. On one hand it would be nice, on the other hand it would suck if you firewall comes up and connects to the internet right away (without being configured for security, no root pwd, etc.) Anybody else have an opinion on this topic? -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Markus W. <ml...@ir...> - 2009-06-06 17:10:13
|
On 06.06.2009 16:10 Heiko Zuerker wrote: > >> The question is - do we really need this feature? > > One part of the DL philosophy is that nothing happens without the > Admin of the Box explicitly allowing it. [...] > Anybody else have an opinion on this topic? My opinion: I agree with your statement above and think that DL doesn't need this feature. Just my 0.02$ Regards, Markus |
From: Bruce S. <bw...@re...> - 2009-06-06 18:27:08
|
>>> Thinking of newbies, could a new install of DL attempt to autoconfigure >>> eth0 i.e. identify and load an appropriate ethernet module and try to >>> pick up IP from an external DHCP server? >> Actually, udev loads all necessary modules during startup. The field >> "module" is >> optional for the simplest cases and allows to define any non-standard options >> for modules (bonding for example). >> So, if we put a prepared ifcfg script for eth0 with DHCP configured then the >> network will start automatically. >> >> The question is - do we really need this feature? > > One part of the DL philosophy is that nothing happens without the > Admin of the Box explicitly allowing it. > I'm unsure about this request. On one hand it would be nice, on the > other hand it would suck if you firewall comes up and connects to the > internet right away (without being configured for security, no root > pwd, etc.) > Anybody else have an opinion on this topic? If a new DL install came online on the Internet, would anyone be able to hack the system? sshd and other services shouldn't be started so is there anyway to connect or login other than the local console? - BS |
From: Heiko Z. <he...@zu...> - 2009-06-06 18:48:29
|
Quoting Bruce Smith <bw...@re...>: >>>> Thinking of newbies, could a new install of DL attempt to autoconfigure >>>> eth0 i.e. identify and load an appropriate ethernet module and try to >>>> pick up IP from an external DHCP server? >>> Actually, udev loads all necessary modules during startup. The field >>> "module" is >>> optional for the simplest cases and allows to define any >>> non-standard options >>> for modules (bonding for example). >>> So, if we put a prepared ifcfg script for eth0 with DHCP >>> configured then the >>> network will start automatically. >>> >>> The question is - do we really need this feature? >> >> One part of the DL philosophy is that nothing happens without the >> Admin of the Box explicitly allowing it. >> I'm unsure about this request. On one hand it would be nice, on the >> other hand it would suck if you firewall comes up and connects to the >> internet right away (without being configured for security, no root >> pwd, etc.) >> Anybody else have an opinion on this topic? > > If a new DL install came online on the Internet, would anyone be able > to hack the system? sshd and other services shouldn't be started so > is there anyway to connect or login other than the local console? He was actually asking for enabling the network, SSH and Webmin. So yes, anybody could connect to it. -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Bruce S. <bw...@re...> - 2009-06-06 18:56:53
|
>> If a new DL install came online on the Internet, would anyone be able >> to hack the system? sshd and other services shouldn't be started so >> is there anyway to connect or login other than the local console? > > He was actually asking for enabling the network, SSH and Webmin. So > yes, anybody could connect to it. Don't know about webmin, but we could configure SSH to not allow root login and/or not allow login to accounts without a password. Maybe we could config webmin to only listen on the internal network nic by default? Or on boot, if an init script detects root doesn't have a password, we could generate and assign a random password to root, and display it on the console. That would keep out remote users. :-) - BS |
From: Heiko Z. <he...@zu...> - 2009-06-06 19:21:07
|
Quoting Bruce Smith <bw...@re...>: >>> If a new DL install came online on the Internet, would anyone be able >>> to hack the system? sshd and other services shouldn't be started so >>> is there anyway to connect or login other than the local console? >> >> He was actually asking for enabling the network, SSH and Webmin. So >> yes, anybody could connect to it. > > Don't know about webmin, but we could configure SSH to not allow root > login and/or not allow login to accounts without a password. > > Maybe we could config webmin to only listen on the internal network > nic by default? > > Or on boot, if an init script detects root doesn't have a password, we > could generate and assign a random password to root, and display it on > the console. That would keep out remote users. :-) Not sure if this would be worth the effort. I'm currently leaning more towards a "No". -- Regards Heiko Zuerker http://www.devil-linux.org ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program. |
From: Bruce S. <bw...@re...> - 2009-06-06 21:46:32
|
>>>> If a new DL install came online on the Internet, would anyone be able >>>> to hack the system? sshd and other services shouldn't be started so >>>> is there anyway to connect or login other than the local console? >>> >>> He was actually asking for enabling the network, SSH and Webmin. So >>> yes, anybody could connect to it. >> >> Don't know about webmin, but we could configure SSH to not allow root >> login and/or not allow login to accounts without a password. >> >> Maybe we could config webmin to only listen on the internal network >> nic by default? >> >> Or on boot, if an init script detects root doesn't have a password, we >> could generate and assign a random password to root, and display it on >> the console. That would keep out remote users. :-) > > Not sure if this would be worth the effort. > I'm currently leaning more towards a "No". I like the idea of automatically loading modules, instead of manually selecting (guessing) them. However, I don't think that should happen automatically. It should be turned on as part of the process of creating an initial manual configuration. Setting root password, configuring firewall, specifying IP addresses or DHCP, and then having it auto load modules. - BS |
From: Dominic R. <dl...@ed...> - 2009-06-06 22:13:15
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> <title></title> </head> <body bgcolor="#ffffff" text="#000000"> On 07/06/2009 00:45, Bruce Smith wrote: <blockquote cite="mid:5f9...@ma..." type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <blockquote type="cite"> <pre wrap="">If a new DL install came online on the Internet, would anyone be able to hack the system? sshd and other services shouldn't be started so is there anyway to connect or login other than the local console? </pre> </blockquote> <pre wrap="">He was actually asking for enabling the network, SSH and Webmin. So yes, anybody could connect to it. </pre> </blockquote> <pre wrap="">Don't know about webmin, but we could configure SSH to not allow root login and/or not allow login to accounts without a password. Maybe we could config webmin to only listen on the internal network nic by default? Or on boot, if an init script detects root doesn't have a password, we could generate and assign a random password to root, and display it on the console. That would keep out remote users. :-) </pre> </blockquote> <pre wrap="">Not sure if this would be worth the effort. I'm currently leaning more towards a "No". </pre> </blockquote> <pre wrap=""><!---->I like the idea of automatically loading modules, instead of manually selecting (guessing) them. However, I don't think that should happen automatically. It should be turned on as part of the process of creating an initial manual configuration. Setting root password, configuring firewall, specifying IP addresses or DHCP, and then having it auto load modules. - BS </pre> </blockquote> Well I recognise the security dangers in an open initial installation but the instructions should make clear that the first thing you must do is login and set a password. DL could come preconfigured with root having a password such as 'devil-linux', which would at least prevent opportunistic casual hacking. Under normal usage you don't need a monitor or keyboard for your DL machine, but you do need it for initial setup; the open bare installation would overcome this and allow plug'n'go.<br> <br> Some possible compromises:<br> - the open installation could be limited to the 'server' flavour of DL, which I guess is aimed towards behind-the-firewall usage (such as I have)?<br> - sshd & webmin are left switched off, but eth0 networking is still autoconfigured for DHCP; or<br> - eth0 networking is not fully autoconfigured but udev's preferred eth0 network module is displayed in Setup. It was news to me that it was optional to specify the network module in Setup. (Finding the right network module for your network card seems to me the hardest thing to explain - short of saying: er, use Google.)<br> <br> But I also recognise the argument that if you make getting started with DL too simple, you just encourage non-experts to have a go, and then they will have problems later. Better if they stick to Ubuntu maybe?<br> <br> Dominic<br> </body> </html> |
From: Serge L. <fi...@in...> - 2009-06-07 06:15:30
|
Dominic Refard wrote: ... > - eth0 networking is not fully autoconfigured but udev's preferred eth0 > network module is displayed in Setup. It was news to me that it was > optional to specify the network module in Setup. (Finding the right > network module for your network card seems to me the hardest thing to > explain - short of saying: er, use Google.) Well... The following code may help with network module identification. for i in $(lsmod | awk '{ print $1}'); do modinfo -F filename $i 2> /dev/null | grep "kernel/drivers/net/" \ | sed -e 's#.*/##' -e 's#\..*$##'; done It prints the list of loaded network modules (previously loaded by udev, of course). > > But I also recognise the argument that if you make getting started with > DL too simple, you just encourage non-experts to have a go, and then > they will have problems later. Better if they stick to Ubuntu maybe? Everybody choses his own way. I think Ubuntu is not the best but definetely not the worst. And you are right, DL is the most attractive for experienced users. -- Sincerely, Serge |
From: Dominic R. <dl...@ed...> - 2009-06-07 08:08:48
|
On 07/06/2009 09:13, Serge Leschinsky wrote: > Dominic Refard wrote: > ... > >> - eth0 networking is not fully autoconfigured but udev's preferred eth0 >> network module is displayed in Setup. It was news to me that it was >> optional to specify the network module in Setup. (Finding the right >> network module for your network card seems to me the hardest thing to >> explain - short of saying: er, use Google.) >> > Well... > The following code may help with network module identification. > > for i in $(lsmod | awk '{ print $1}'); > do > modinfo -F filename $i 2> /dev/null | grep "kernel/drivers/net/" \ > | sed -e 's#.*/##' -e 's#\..*$##'; > done > > It prints the list of loaded network modules (previously loaded by udev, of course). > Neat, and I've added it to my how-to page, but it's unlikely a newcomer could type this all in perfectly, and of course they can't cut'n'paste at this stage. I guess it would not be necessary if your idea of having an 'autodetect' option in setup is followed. Dominic |
From: Serge L. <fi...@in...> - 2009-06-07 19:39:53
|
Dominic Refard wrote: > On 07/06/2009 09:13, Serge Leschinsky wrote: >> Dominic Refard wrote: >> ... >> >>> - eth0 networking is not fully autoconfigured but udev's preferred eth0 >>> network module is displayed in Setup. It was news to me that it was >>> optional to specify the network module in Setup. (Finding the right >>> network module for your network card seems to me the hardest thing to >>> explain - short of saying: er, use Google.) >>> >> Well... >> The following code may help with network module identification. >> >> for i in $(lsmod | awk '{ print $1}'); >> do >> modinfo -F filename $i 2> /dev/null | grep "kernel/drivers/net/" \ >> | sed -e 's#.*/##' -e 's#\..*$##'; >> done >> >> It prints the list of loaded network modules (previously loaded by udev, of course). >> > Neat, and I've added it to my how-to page Hm... It was just an example, moreover I considered this code to be used in 'setup' tool. For howto page I'd rather suggest 'lspci' based variant lspci -v | grep "Ethernet controller:\|Kernel modules:" | \ grep -A1 "Ethernet controller:" > could type this all in perfectly, and of course they can't cut'n'paste > at this stage. I guess it would not be necessary if your idea of having > an 'autodetect' option in setup is followed. I tried several times to modify 'setup' and have to admit it's not so easy. This magic is too difficult for me... Bruce is the main wizard. Serge |
From: Serge L. <fi...@in...> - 2009-06-07 05:41:55
|
Bruce Smith wrote: >>>>> If a new DL install came online on the Internet, would anyone be able >>>>> to hack the system? sshd and other services shouldn't be started so >>>>> is there anyway to connect or login other than the local console? >>>> He was actually asking for enabling the network, SSH and Webmin. So >>>> yes, anybody could connect to it. >>> Don't know about webmin, but we could configure SSH to not allow root >>> login and/or not allow login to accounts without a password. >>> >>> Maybe we could config webmin to only listen on the internal network >>> nic by default? >>> >>> Or on boot, if an init script detects root doesn't have a password, we >>> could generate and assign a random password to root, and display it on >>> the console. That would keep out remote users. :-) >> Not sure if this would be worth the effort. >> I'm currently leaning more towards a "No". > > I like the idea of automatically loading modules, instead of manually > selecting (guessing) them. > Bruce, you can add to the list of modules something like "autodetect" and if a user chooses it, just to not write anything in the MODULE parameter, i.e. MODULE="". In this case the task of network module loading will be delegated to udev. Usually udev manages to do it. Serge |
From: Herbert K. <her...@gm...> - 2009-06-07 10:54:53
|
Heiko Zuerker wrote: > One part of the DL philosophy is that nothing happens without the > Admin of the Box explicitly allowing it. 100% agree! Herbert |
From: Dominic R. <dl...@ed...> - 2009-06-04 15:13:11
|
> > ... Webmin is very cool. Note that the default settings for module 'Samba > Windows File Sharing' in Webmin assume all key files are in > /usr/local/samba/bin which ain't so; once I fix these the module seems > to work well... Also for apache module I needed to change: Path to httpd executable: /usr/sbin/httpd Path to the apachectl command: /usr/sbin/apachectl |