devil-linux-discuss — General Mailing List for all discussions

[Devil-Linux-discuss] UMTS USB modem

[<Her...@sp...>]

Hi List

I'm lookig for an USB UMTS modem which works with devil-linux.

Has anybody ever set up something like this and can give some hints like
what product to use and how to configure it?

Thanks and regards,

Herbert

Re: [Devil-Linux-discuss] Something wrong with svn-version?

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

>> it's seems thats my mistake - i untar the lfssystem as unprivileged
>> user, but this fail.
>> With the same doing as root all works fine. Perhaps it should be
>> remarked in the online-documentation?
>
> Yes it should. ;-)
> It'll happen as soon as we find a new documentation maintainer...

To keep it simple, we should probably simply state that ALL
development tasks should be done as root, instead of trying to list
all the individual items.

 - BS

Re: [Devil-Linux-discuss] Something wrong with svn-version?

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

Quoting Udo Lembke <udo...@al...>:

> Hi Heiko,
> it's seems thats my mistake - i untar the lfssystem as unprivileged
> user, but this fail.
> With the same doing as root all works fine. Perhaps it should be
> remarked in the online-documentation?

Yes it should. ;-)
It'll happen as soon as we find a new documentation maintainer...

-- 

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


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Devil-Linux-discuss] [Devil-Linux 1.4 0000066]: virtio-access produce IO-Errors

[Udo L. <udo...@al...>]

Hi Serge,
thanks for your work! Yes, with the new kernel i don't get any error 
messages.

Best regards

Udo Lembke

Serge Leschinsky schrieb:
> Hi Udo,
>
> I checked the scenario you described (DL with virtio block device in KVM ) - the
> problem seems to be fixed in 2.6.32.10, so I've closed the bug.
>
> Please let us know if something is still broken.
>
> Sincerely,
> Serge
>
>
>   

Re: [Devil-Linux-discuss] Something wrong with svn-version?

[Udo L. <udo...@al...>]

Hi Heiko,
it's seems thats my mistake - i untar the lfssystem as unprivileged 
user, but this fail.
With the same doing as root all works fine. Perhaps it should be 
remarked in the online-documentation?

Thank you.

Udo Lembke

Heiko Zuerker schrieb:
> I just compiled a version of DL and didn't have any problems.
> Update from CVS & FTP and give it another try (with fresh lfssystem of
> course).
>
> Heiko
>
>   

Re: [Devil-Linux-discuss] [Devil-Linux 1.4 0000066]: virtio-access produce IO-Errors

[Serge L. <fi...@in...>]

Hi Udo,

I checked the scenario you described (DL with virtio block device in KVM ) - the
problem seems to be fixed in 2.6.32.10, so I've closed the bug.

Please let us know if something is still broken.

Sincerely,
Serge


On 03/27/2010 08:36 AM, Udo Lembke wrote:
> Hi Serge,
> sorry for the delayed answer. I'm also not a kernel hacker, but you are
> right, the part looks different (but alos different like the patch).
> For reproducing it's enough to run devil-linux with an virtio-disk in a
> kvm-session - all work's but the error fill /var/log/messages. The easies
> way is using proxmox for this (http://pve.proxmox.com/wiki/Downloads).
> But you need a 64bit computer with hardwarevirtualisation and a blank disk
> (proxmox-pve erase the whole disk). With proxmox-pve you can create and
> manage the kvm (and openvz) guest from a web-gui.
> 
> I have tried the svn-version but i failed at building... (the posting
> before of me).
> 
> And thanks a lot for the work at devil-linux - it's a very nice distribution.
> 
> Best regards
> 
> Udo
> 
>> Udo,
>>
>> you are welcome.
>> I've perused the patch and the bug description, then compared it with the
>> recent
>> kernel patch 2.6.32.10. The patch seems to be integrated.
>>
>> Please take a look:
>>
>> Patch:
>> -----------------------------------------------------------------------
>> #  end_request: I/O error, dev vda, sector 0
>> #  end_request: I/O error, dev vda, sector 0
>> #  commit 52b1fd5a27c625c78373e024bf570af3c9d44a79
>> #  Author: Mikulas Patocka <mpa...@re...>
>> #    dm: send empty barriers to targets in dm_flush
>> #  https://bugzilla.redhat.com/514901
>> # block/blk-core.c |    3 +--
>> # 1 files changed, 1 insertions(+), 2 deletions(-)
>> --- a/block/blk-core.c
>> +++ a/block/blk-core.c
>> @@ -1163,8 +1163,7 @@ static int __make_request(struct request_queue *q,
>> struct
>> bio *bio)
>>         const int unplug = bio_unplug(bio);
>>         int rw_flags;
>>
>> -       if (bio_barrier(bio) && bio_has_data(bio) &&
>> -           (q->next_ordered == QUEUE_ORDERED_NONE)) {
>> +       if (bio_barrier(bio) && (q->next_ordered == QUEUE_ORDERED_NONE)) {
>>                 bio_endio(bio, -EOPNOTSUPP);
>>                 return 0;
>>         }
>>
>>
>> Kernel code:
>> -----------------------------------------------------------------------
>>         int rw_flags;
>>
>>         if (bio_rw_flagged(bio, BIO_RW_BARRIER) &&
>>             (q->next_ordered == QUEUE_ORDERED_NONE)) {
>>                 bio_endio(bio, -EOPNOTSUPP);
>>                 return 0;
>>         }
>> -----------------------------------------------------------------------
>> I'm not a kernel hacker though and can be wrong...
>>
>>  Could you please help me with the issue reproducing?
>>
>> Serge
>>
>>
> 
> 
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss
> 

Re: [Devil-Linux-discuss] 2.6.32 ralink ethernet

[Dick M. <di...@fo...>]

On 03/29/10 16:25, Ashwin wrote:
> On 29-Mar-10 2:08 PM, Dick Middleton wrote:
>> Has anybody else seen the following behaviour:
>>
>> I've got a via mini-itx board which I use as a diskless client using
>> stock Debian.  The root disk is an nbd device and I boot using PXE. The
>> mini-itx board has 2 net interfaces of type Ralink RTL-8110SC/8169SC
>> which uses the r8169 driver.
>>
>> On 2.6.30 this all works fine.  On 2.6.32 the MAC address of the net
>> interface gets corrupted somehow.  The MAC address is correct at cold
>> boot and the system starts but if a reboot takes place or even a power
>> cycle using the power switch or a reset then the net interface has the
>> first 4 octets of the MAC address set to zero.  Only completely removing
>> power from the system will restore the MAC address and allow reboot.
>> This is quite consistent and repeatable on my system.
>>
>> Debian has changed between 2.6.30 and 2.6.32 to remove non-free firmware
>> but so far as I know this net card does not use downloadable firmware so
>> I suspect that this is a problem with the r8169 driver.
>>
>> As Devil is probably quite often used on mini-itx and DL is going to
>> settle on 2.6.32 I thought this might be relevant.
>>
>> Dick
>>
> 
> I have a doubt about the udev rules for this interface, is it possible 
> to check the same ?

That's OK.  The problem is it actually changes the MAC address so it is
incorrect at boot time (in the bios, before any system is loaded).  The
change must take place at shutdown because all is correct whilst system
is running.

This problem might not be seen on a normal system.  It's only because
PXE uses DHCP to get to boot files that it becomes critical.  However it
is possible that the MAC address is being changed on 'ordinary' systems
but the change is not noticed.

I have found reports of bootup strangeness with r8169 driver which I
suspect is the same problem.  I've seen udev blamed in one report when
the information given shows the MAC address has changed. An incorrect
diagnosis I think!  I've also seen the driver being blamed for *reading*
the MAC incorrectly.  In my case that's not the symptom.

Anyway, I'd be curious if anyone sees a similar effect; maybe check MAC
with ifconfig after rebooting.

Dick

-- 
Dick Middleton
di...@fo...
PGP Key ID: 0x9F9434FD

Re: [Devil-Linux-discuss] 2.6.32 ralink ethernet

[Ashwin <ash...@gm...>]

On 29-Mar-10 2:08 PM, Dick Middleton wrote:
> Has anybody else seen the following behaviour:
>
> I've got a via mini-itx board which I use as a diskless client using
> stock Debian.  The root disk is an nbd device and I boot using PXE. The
> mini-itx board has 2 net interfaces of type Ralink RTL-8110SC/8169SC
> which uses the r8169 driver.
>
> On 2.6.30 this all works fine.  On 2.6.32 the MAC address of the net
> interface gets corrupted somehow.  The MAC address is correct at cold
> boot and the system starts but if a reboot takes place or even a power
> cycle using the power switch or a reset then the net interface has the
> first 4 octets of the MAC address set to zero.  Only completely removing
> power from the system will restore the MAC address and allow reboot.
> This is quite consistent and repeatable on my system.
>
> Debian has changed between 2.6.30 and 2.6.32 to remove non-free firmware
> but so far as I know this net card does not use downloadable firmware so
> I suspect that this is a problem with the r8169 driver.
>
> As Devil is probably quite often used on mini-itx and DL is going to
> settle on 2.6.32 I thought this might be relevant.
>
> Dick
>

I have a doubt about the udev rules for this interface, is it possible 
to check the same ?

with Regards,
ASHWIN

[Devil-Linux-discuss] 2.6.32 ralink ethernet

[Dick M. <di...@fo...>]

Has anybody else seen the following behaviour:

I've got a via mini-itx board which I use as a diskless client using
stock Debian.  The root disk is an nbd device and I boot using PXE. The
mini-itx board has 2 net interfaces of type Ralink RTL-8110SC/8169SC
which uses the r8169 driver.

On 2.6.30 this all works fine.  On 2.6.32 the MAC address of the net
interface gets corrupted somehow.  The MAC address is correct at cold
boot and the system starts but if a reboot takes place or even a power
cycle using the power switch or a reset then the net interface has the
first 4 octets of the MAC address set to zero.  Only completely removing
power from the system will restore the MAC address and allow reboot.
This is quite consistent and repeatable on my system.

Debian has changed between 2.6.30 and 2.6.32 to remove non-free firmware
but so far as I know this net card does not use downloadable firmware so
I suspect that this is a problem with the r8169 driver.

As Devil is probably quite often used on mini-itx and DL is going to
settle on 2.6.32 I thought this might be relevant.

Dick

-- 
Dick Middleton
di...@fo...
PGP Key ID: 0x9F9434FD

Re: [Devil-Linux-discuss] Something wrong with svn-version?

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

I just compiled a version of DL and didn't have any problems.
Update from CVS & FTP and give it another try (with fresh lfssystem of
course).

Heiko

> -----Original Message-----
> From: Udo Lembke [mailto:udo...@al...]
> Sent: Saturday, March 27, 2010 10:06 AM
> To: dev...@li...
> Subject: [Devil-Linux-discuss] Something wrong with svn-version?
> 
> Hi,
> i need some help. I have tried on two computer build a system from
> svn and
> stuck at the same point. My first try was with an old lvs-system,
> but the
> second try start from a clean system.
> 
> It seems. that /dev/null is not correct, but it's fails also if i
> copy a
> "right" /dev/null. Perhaps the Algiers tz-info is damage?
> 
> Here comes the output:
> 
> root:/build# make build
> mount: proc already mounted
> mount: none already mounted or /sys busy
> mount: according to mtab, none is already mounted on /sys
> make: Entering directory `/build'
> build: prepare                                  log:
> /build/tmp/LOGS/build/prepare
> build: glibc                                    log:
> /build/tmp/LOGS/build/glibc
> make: *** [glibc] Error 1
> make: Leaving directory `/build'
> make: *** [build] Error 1
> 
> 
> root:/build# tail -8 /build/tmp/LOGS/build/glibc
> "/dev/null", line 4854: input line of unknown type
> "/dev/null", line 4855: input line of unknown type
> "/dev/null", line 4856: input line of unknown type
> make[2]: ***
> [/build/tmp/tmp.glibc.17200/usr/share/zoneinfo/Africa/Algiers]
> Error 1
> make[2]: Leaving directory `/build/tmp/glibc-2.5.1/timezone'
> make[1]: *** [timezone/subdir_install] Error 2
> make[1]: Leaving directory `/build/tmp/glibc-2.5.1'
> make: *** [install] Error 2
> 
> root:/build# ls -lsa /dev/null
> 276 -rwxr-xr-x 1 root root 274464 Mar 27 07:49 /dev/null
> 
> Any hint?
> 
> Best regards
> 
> Udo
> 
> 
> -------------------------------------------------------------------
> -----------
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Devil-linux-discuss mailing list
> Dev...@li...
> https://lists.sourceforge.net/lists/listinfo/devil-linux-discuss

Re: [Devil-Linux-discuss] [Devil-Linux 1.4 0000066]: virtio-access produce IO-Errors

[Udo L. <udo...@al...>]

Hi Serge,
sorry for the delayed answer. I'm also not a kernel hacker, but you are
right, the part looks different (but alos different like the patch).
For reproducing it's enough to run devil-linux with an virtio-disk in a
kvm-session - all work's but the error fill /var/log/messages. The easies
way is using proxmox for this (http://pve.proxmox.com/wiki/Downloads).
But you need a 64bit computer with hardwarevirtualisation and a blank disk
(proxmox-pve erase the whole disk). With proxmox-pve you can create and
manage the kvm (and openvz) guest from a web-gui.

I have tried the svn-version but i failed at building... (the posting
before of me).

And thanks a lot for the work at devil-linux - it's a very nice distribution.

Best regards

Udo

> Udo,
>
> you are welcome.
> I've perused the patch and the bug description, then compared it with the
> recent
> kernel patch 2.6.32.10. The patch seems to be integrated.
>
> Please take a look:
>
> Patch:
> -----------------------------------------------------------------------
> #  end_request: I/O error, dev vda, sector 0
> #  end_request: I/O error, dev vda, sector 0
> #  commit 52b1fd5a27c625c78373e024bf570af3c9d44a79
> #  Author: Mikulas Patocka <mpa...@re...>
> #    dm: send empty barriers to targets in dm_flush
> #  https://bugzilla.redhat.com/514901
> # block/blk-core.c |    3 +--
> # 1 files changed, 1 insertions(+), 2 deletions(-)
> --- a/block/blk-core.c
> +++ a/block/blk-core.c
> @@ -1163,8 +1163,7 @@ static int __make_request(struct request_queue *q,
> struct
> bio *bio)
>         const int unplug = bio_unplug(bio);
>         int rw_flags;
>
> -       if (bio_barrier(bio) && bio_has_data(bio) &&
> -           (q->next_ordered == QUEUE_ORDERED_NONE)) {
> +       if (bio_barrier(bio) && (q->next_ordered == QUEUE_ORDERED_NONE)) {
>                 bio_endio(bio, -EOPNOTSUPP);
>                 return 0;
>         }
>
>
> Kernel code:
> -----------------------------------------------------------------------
>         int rw_flags;
>
>         if (bio_rw_flagged(bio, BIO_RW_BARRIER) &&
>             (q->next_ordered == QUEUE_ORDERED_NONE)) {
>                 bio_endio(bio, -EOPNOTSUPP);
>                 return 0;
>         }
> -----------------------------------------------------------------------
> I'm not a kernel hacker though and can be wrong...
>
>  Could you please help me with the issue reproducing?
>
> Serge
>
>

[Devil-Linux-discuss] Something wrong with svn-version?

[Udo L. <udo...@al...>]

Hi,
i need some help. I have tried on two computer build a system from svn and
stuck at the same point. My first try was with an old lvs-system, but the
second try start from a clean system.

It seems. that /dev/null is not correct, but it's fails also if i copy a
"right" /dev/null. Perhaps the Algiers tz-info is damage?

Here comes the output:

root:/build# make build
mount: proc already mounted
mount: none already mounted or /sys busy
mount: according to mtab, none is already mounted on /sys
make: Entering directory `/build'
build: prepare                                  log:
/build/tmp/LOGS/build/prepare
build: glibc                                    log:
/build/tmp/LOGS/build/glibc
make: *** [glibc] Error 1
make: Leaving directory `/build'
make: *** [build] Error 1


root:/build# tail -8 /build/tmp/LOGS/build/glibc
"/dev/null", line 4854: input line of unknown type
"/dev/null", line 4855: input line of unknown type
"/dev/null", line 4856: input line of unknown type
make[2]: ***
[/build/tmp/tmp.glibc.17200/usr/share/zoneinfo/Africa/Algiers] Error 1
make[2]: Leaving directory `/build/tmp/glibc-2.5.1/timezone'
make[1]: *** [timezone/subdir_install] Error 2
make[1]: Leaving directory `/build/tmp/glibc-2.5.1'
make: *** [install] Error 2

root:/build# ls -lsa /dev/null
276 -rwxr-xr-x 1 root root 274464 Mar 27 07:49 /dev/null

Any hint?

Best regards

Udo

Re: [Devil-Linux-discuss] [Devil-Linux 1.4 0000066]: virtio-access produce IO-Errors

[Serge L. <fi...@in...>]

Udo,

you are welcome.
I've perused the patch and the bug description, then compared it with the recent
kernel patch 2.6.32.10. The patch seems to be integrated.

Please take a look:

Patch:
-----------------------------------------------------------------------
#  end_request: I/O error, dev vda, sector 0
#  end_request: I/O error, dev vda, sector 0
#  commit 52b1fd5a27c625c78373e024bf570af3c9d44a79
#  Author: Mikulas Patocka <mpa...@re...>
#    dm: send empty barriers to targets in dm_flush
#  https://bugzilla.redhat.com/514901
# block/blk-core.c |    3 +--
# 1 files changed, 1 insertions(+), 2 deletions(-)
--- a/block/blk-core.c
+++ a/block/blk-core.c
@@ -1163,8 +1163,7 @@ static int __make_request(struct request_queue *q, struct
bio *bio)
        const int unplug = bio_unplug(bio);
        int rw_flags;

-       if (bio_barrier(bio) && bio_has_data(bio) &&
-           (q->next_ordered == QUEUE_ORDERED_NONE)) {
+       if (bio_barrier(bio) && (q->next_ordered == QUEUE_ORDERED_NONE)) {
                bio_endio(bio, -EOPNOTSUPP);
                return 0;
        }


Kernel code:
-----------------------------------------------------------------------
        int rw_flags;

        if (bio_rw_flagged(bio, BIO_RW_BARRIER) &&
            (q->next_ordered == QUEUE_ORDERED_NONE)) {
                bio_endio(bio, -EOPNOTSUPP);
                return 0;
        }
-----------------------------------------------------------------------
I'm not a kernel hacker though and can be wrong...

 Could you please help me with the issue reproducing?

Serge

On 03/18/2010 07:47 AM, SourceForge.net: Mantis Bug Tracker: project :
devil-linux wrote:
> 
> The following issue has been SUBMITTED. 
> ====================================================================== 
> https://sourceforge.net/apps/mantisbt/devil-linux/view.php?id=66 
> ====================================================================== 
> Reported By:                ulembke
> Assigned To:                
> ====================================================================== 
> Project:                    Devil-Linux 1.4
> Issue ID:                   66
> Category:                   Bug
> Reproducibility:            always
> Severity:                   minor
> Priority:                   normal
> Status:                     new
> ====================================================================== 
> Date Submitted:             2010-03-18 14:47 UTC
> Last Modified:              2010-03-18 14:47 UTC
> ====================================================================== 
> Summary:                    virtio-access produce IO-Errors
> Description: 
> Fist i have to thank you for the fast solution about the
> virtio-configstore.
> Unfortunately produce the usage of virtio with lvm an error:
> end_request: I/O error, dev vda, sector 0
> 
> There is a fix for that bug:
> http://lkml.org/lkml/2009/8/6/153
> 
> Perhaps it's possible to patch the kernel?
> 
> Best regards
> 
> Udo
> ====================================================================== 
> 
> Issue History 
> Date Modified    Username       Field                    Change               
> ====================================================================== 
> 2010-03-18 14:47 ulembke        New Issue                                    
> ======================================================================
> 
> 

Re: [Devil-Linux-discuss] Ping Downgraded from 1.2.15 to 1.4

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

> -----Original Message-----
> From: Bradlee Landis [mailto:bra...@gm...]
> Sent: Wednesday, March 10, 2010 4:04 PM
> To: dev...@li...
> Subject: [Devil-Linux-discuss] Ping Downgraded from 1.2.15 to 1.4
> 
> Just out of curiosity, did DL intentionally downgrade the ping
> utility, or was it done upstream at LFS? On 1.4RC1, it returns this
> version number: "ping - GNU inetutils 1.5", while on 1.2.15, it
> returns this: "ping utility, iputils-ss020927". The version in
> iputils
> seems to be better to me. It includes a flag for broadcast (-b) and
> interface (-I) and both are features that I would like to make use
> of,
> but neither are in inetutils.
> 
> I'm kind of disappointed in inetutils, as it is a program by GNU.
> iputils seems to be run by a single person, and hasn't been updated
> in
> a few years, but it seems to be better just from the options list.

We switch it last year November from inetutils back to iputils.
Use RC3, it has a lot of fixes compared to RC1 and RC2.


Heiko

[Devil-Linux-discuss] Ping Downgraded from 1.2.15 to 1.4

[Bradlee L. <bra...@gm...>]

Just out of curiosity, did DL intentionally downgrade the ping
utility, or was it done upstream at LFS? On 1.4RC1, it returns this
version number: "ping - GNU inetutils 1.5", while on 1.2.15, it
returns this: "ping utility, iputils-ss020927". The version in iputils
seems to be better to me. It includes a flag for broadcast (-b) and
interface (-I) and both are features that I would like to make use of,
but neither are in inetutils.

I'm kind of disappointed in inetutils, as it is a program by GNU.
iputils seems to be run by a single person, and hasn't been updated in
a few years, but it seems to be better just from the options list.


Thanks,
Brad Landis

Re: [Devil-Linux-discuss] Feature request (backup config files)

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

Quoting Heiko Zuerker <he...@zu...>:

> Quoting Steve Ralph <Ste...@sa...>:
>
>> Hi everyone again,
>>
>> A colleague suggested that if the box did boot into a previous
>> config file then it would be nice to see this in the Login Prompt.
>> This would be good for headless boxes where the main access is SSH
>> and would be an immediate visual clue that something is not quite
>> right!
>
> Patches are more than welcome folks. ;-)
>
> Here are some gotchas:
> - save-config would have to take into account the available disk space
> on the device
> - if a sign config is used, only a signed backup can be loaded
> (otherwise it would be too easy to hack)
> - save-config should always write out a checksum with the
> etc-mod.tar.bz2 in order to validate if it's good (we should do that
> anyway)

I'm pretty busy lately and won't be able to implement this feature  
request, so if anybody feels like doing it and then submitting a  
patch.... :)

Otherwise please create a feature request in Mantis.

-- 

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


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Devil-Linux-discuss] Feature request (backup config files)

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

Quoting Steve Ralph <Ste...@sa...>:

> Hi everyone again,
>
> A colleague suggested that if the box did boot into a previous  
> config file then it would be nice to see this in the Login Prompt.
> This would be good for headless boxes where the main access is SSH  
> and would be an immediate visual clue that something is not quite  
> right!

Patches are more than welcome folks. ;-)

Here are some gotchas:
- save-config would have to take into account the available disk space  
on the device
- if a sign config is used, only a signed backup can be loaded  
(otherwise it would be too easy to hack)
- save-config should always write out a checksum with the  
etc-mod.tar.bz2 in order to validate if it's good (we should do that  
anyway)

-- 

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


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Devil-Linux-discuss] Feature request (backup config files)

[Steve R. <Ste...@sa...>]

Hi everyone again,

A colleague suggested that if the box did boot into a previous config file then it would be nice to see this in the Login Prompt.
This would be good for headless boxes where the main access is SSH and would be an immediate visual clue that something is not quite right!

Regards - Steve.

Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell
Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Tel: 0121 569 3132 | Fax: 0121 569 3493
Email: ste...@sa...

Re: [Devil-Linux-discuss] Feature request (backup config files)

[Steve R. <Ste...@sa...>]

Hi everyone!

I think this idea to have automatic access to backup config files makes a lot of sense.

>>> If you really want to be complete save-config could increment the version number.
I'd support this - save config could either brand the date-timestamp into the filename or just increment a sequence number.

If the system has a configured system-clock, then I routinely use a bash script code fragment like:

        myDateStamp=`date +"-%Y%m%d-%H%M%S"`
        myFileName="`uname -n`${myDateStamp}"
        tar czvf ./${myFileName}.tgz --files-from=/somewhere/over/the/rainbow/file-list"

 to generate a filename of "daffodil.mydomain.gov.uk-20100309-175916.tgz".

If the date-timestamp idea doesn't appeal, then I'd suggest filenames built in the same way that /var/log/ files are named and logrotated.

A special logrotate script could control the number of previous configs to be kept just before save-config generates a new one.

I am testing a logrotate script that successfully handles filenames like "daffodil.mydomain.gov.uk-20100309-175916.tgz" and can post it if anyone is interested.

Regards - Steve.

Stephen H F Ralph
Principal Computer Officer | Integration Team | ICT Services | Transform Sandwell
Sandwell MBC | Freeth Street | Oldbury | West Midlands | B69 3DE
Tel: 0121 569 3132 | Fax: 0121 569 3493
Email: ste...@sa...

Re: [Devil-Linux-discuss] Feature request

[Dick M. <di...@fo...>]

Her...@sp... wrote:
> Dick Middleton <di...@fo...> wrote on 09.03.2010 08:42:00:
>> Heiko Zuerker wrote:
>>> Quoting Her...@sp...:
>>>> What do you think about this?
>>> Not a bad idea.
>>> We need a naming standard for the backup file.
>>> The backup file would be created manually because of the signature,
> correct?
>> I would generalise it:  use a version number - at boot sys scans round
>> looking for all etc-mod.<ver>.tar.bz2 and loads the one with highest
>> version.
>>
>> If you really want to be complete save-config could increment the
>> version nnumber.
> 
> Sounds good, but then I think, save-config should not keep more then a
> handfull of versions, maybe ten.
> A save-config run could move all backup files to the next version number.
> But if using multiple versions, the boot process needs to loop back the
> versions until it finds one with a valid signature in case signatures are
> used.

I'm not so sure about the save-config thing now.  I was having breakfast 
at the time so no thought given.  Problem is there may well be more than 
one device involved but not necessarily present so it might be difficult 
to choose reliably a new version number.  Better to keep it simple.

I would go with numbers though, even if only because it saves having to 
think of a name! :)

Dick

Re: [Devil-Linux-discuss] Feature request

[<Her...@sp...>]

Dick Middleton <di...@fo...> wrote on 09.03.2010 08:42:00:
> Heiko Zuerker wrote:
> > Quoting Her...@sp...:
>
> >> What do you think about this?
> >
> > Not a bad idea.
> > We need a naming standard for the backup file.
> > The backup file would be created manually because of the signature,
correct?
>
> I would generalise it:  use a version number - at boot sys scans round
> looking for all etc-mod.<ver>.tar.bz2 and loads the one with highest
> version.
>
> If you really want to be complete save-config could increment the
> version nnumber.

Sounds good, but then I think, save-config should not keep more then a
handfull of versions, maybe ten.
A save-config run could move all backup files to the next version number.
But if using multiple versions, the boot process needs to loop back the
versions until it finds one with a valid signature in case signatures are
used.

I can work with either of the two mentioned solutions...

Herbert

Re: [Devil-Linux-discuss] Feature request

[Dick M. <di...@fo...>]

Heiko Zuerker wrote:
> Quoting Her...@sp...:

>> What do you think about this?
> 
> Not a bad idea.
> We need a naming standard for the backup file.
> The backup file would be created manually because of the signature, correct?

I would generalise it:  use a version number - at boot sys scans round 
looking for all etc-mod.<ver>.tar.bz2 and loads the one with highest 
version.

If you really want to be complete save-config could increment the 
version nnumber.

Dick

Re: [Devil-Linux-discuss] Feature request

[<Her...@sp...>]

Heiko Zuerker <he...@zu...> wrote on 08.03.2010 21:22:48:
>
> Quoting Her...@sp...:
>
> > Heiko Zuerker <he...@zu...> wrote on 08.03.2010 15:01:17:
> >
> >> >
> >> > Hi List
> >> >
> >> > I'm glad to hear that DL 1.4 is making progress! Lately, I have
tested
> > RC2
> >> > and in my environment, it runs stable. I run it from a write
protected
> > CF
> >> > card in a nexcom NSA appliance. The config file is loaded from a USB
> > stick.
> >> >
> >> > I'm using the feature with the signed config file and it works grat
for
> > me,
> >> > as long as the signature is valid. Here I'd like to have the
following
> >> > functionality:
> >> > If the signature of the config file is not valid, the system should
ask
> > if
> >> > it should continue to load it (as it does already). If this question
> > times
> >> > out or is not confirmed, the system should load a backup config file
if
> > the
> >> > signature of the backup config file is valid.
> >> >
> >> > Doing this, we have a fallback configuration, in case the main
> >> > configuration is not valid for some reason, and the system can still
be
> >> > operated from remote and the problem with the main configuration can
be
> >> > fixed.
> >> >
> >> > What do you think about this?
> >>
> >> Not a bad idea.
> >> We need a naming standard for the backup file.
> >> The backup file would be created manually because of the signature,
> > correct?
> >>
> >
> > I'm glad you like the idea.
> >
> > What about etc-mods-fb.tar.bz2 or etc-mods-fallback.tar.bz2?
>
> How about etc-mods.bak.tar.bz2?
> That reminds be of the good old (not really) DOS days.... ;-)
>

Fine... when can I test :-)

Re: [Devil-Linux-discuss] Feature request

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

Quoting Her...@sp...:

> Heiko Zuerker <he...@zu...> wrote on 08.03.2010 15:01:17:
>
>> >
>> > Hi List
>> >
>> > I'm glad to hear that DL 1.4 is making progress! Lately, I have tested
> RC2
>> > and in my environment, it runs stable. I run it from a write protected
> CF
>> > card in a nexcom NSA appliance. The config file is loaded from a USB
> stick.
>> >
>> > I'm using the feature with the signed config file and it works grat for
> me,
>> > as long as the signature is valid. Here I'd like to have the following
>> > functionality:
>> > If the signature of the config file is not valid, the system should ask
> if
>> > it should continue to load it (as it does already). If this question
> times
>> > out or is not confirmed, the system should load a backup config file if
> the
>> > signature of the backup config file is valid.
>> >
>> > Doing this, we have a fallback configuration, in case the main
>> > configuration is not valid for some reason, and the system can still be
>> > operated from remote and the problem with the main configuration can be
>> > fixed.
>> >
>> > What do you think about this?
>>
>> Not a bad idea.
>> We need a naming standard for the backup file.
>> The backup file would be created manually because of the signature,
> correct?
>>
>
> I'm glad you like the idea.
>
> What about etc-mods-fb.tar.bz2 or etc-mods-fallback.tar.bz2?

How about etc-mods.bak.tar.bz2?
That reminds be of the good old (not really) DOS days.... ;-)

-- 

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


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Devil-Linux-discuss] Feature request

[<Her...@sp...>]

Heiko Zuerker <he...@zu...> wrote on 08.03.2010 15:01:17:

> >
> > Hi List
> >
> > I'm glad to hear that DL 1.4 is making progress! Lately, I have tested
RC2
> > and in my environment, it runs stable. I run it from a write protected
CF
> > card in a nexcom NSA appliance. The config file is loaded from a USB
stick.
> >
> > I'm using the feature with the signed config file and it works grat for
me,
> > as long as the signature is valid. Here I'd like to have the following
> > functionality:
> > If the signature of the config file is not valid, the system should ask
if
> > it should continue to load it (as it does already). If this question
times
> > out or is not confirmed, the system should load a backup config file if
the
> > signature of the backup config file is valid.
> >
> > Doing this, we have a fallback configuration, in case the main
> > configuration is not valid for some reason, and the system can still be
> > operated from remote and the problem with the main configuration can be
> > fixed.
> >
> > What do you think about this?
>
> Not a bad idea.
> We need a naming standard for the backup file.
> The backup file would be created manually because of the signature,
correct?
>

I'm glad you like the idea.

What about etc-mods-fb.tar.bz2 or etc-mods-fallback.tar.bz2?

Regards,

Herbert