28 Sep
2004
28 Sep
'04
8:41 a.m.
Hello Alain
First let me thanks you for this not enough known but great application (it
allows me to save a laptop hard drive where commercial product like Acronis
just fails and open source g4u didn't recognize the network card).
I'm considering using this product to save special configurations with PXE. I
successfully tested it with the linux24 precompiled kernel (the linux26 fails
to detect my USB keyboard). To avoid the menu options witch will be the same
accross my network I tried to use the documented keywords like those described
in http://www.udpcast.linux.lu/current/bootloader.html in the default file
after the append keyword( append initrd=initrd disk=/dev/hda umode=snd
auto=yes). I read a previous post that says that only the first 6 parameter are
taken into account. Here it just doesnt't work. Do you know if it's a kernel
configuration problem ? Is there a workaround (for example putting those
parameters in a another configuration file) to avoid the menus ?
A few words about an added feature I would like to have :
I would like to have several process waiting on my linux server ready to backup
several hosts in their owns "file.img". That implies at least two things :
The possibility to generate a unique file name for each different client (One
approach would be to send the mac address from the client and to use it with a
time stamp on the server).
The possibility for the receiver to be split in a daemon part that never quits
and a child process to be spawned for each client. For that part maybe it could
be easier to use in the middle an http server and a cgi script.
Do you think it's doable and what would be the difficulty to implement it ?
Thanks for your feedback.
Bernard.
30 Sep
30 Sep
7:55 p.m.
On Tuesday 28 September 2004 10:41, Bernard Chatin wrote:
Hello Alain
First let me thanks you for this not enough known but great application (it
allows me to save a laptop hard drive where commercial product like Acronis
just fails and open source g4u didn't recognize the network card).
I'm considering using this product to save special configurations with PXE.
I successfully tested it with the linux24 precompiled kernel (the linux26
fails to detect my USB keyboard). To avoid the menu options witch will be
the same accross my network I tried to use the documented keywords like
those described in http://www.udpcast.linux.lu/current/bootloader.html in
the default file after the append keyword( append initrd=initrd
disk=/dev/hda umode=snd auto=yes). I read a previous post that says that
only the first 6 parameter are taken into account. Here it just doesnt't
work. Do you know if it's a kernel configuration problem ?
I haven't yet found the reason why this it only takes the 6 first
parameters...
Is there a
workaround (for example putting those parameters in a another configuration
file) to avoid the menus ?
Yes, you can include a /udpcfg.txt file into the initrd image using
the --savefile option of the makeImage script.
The savefile is a text file that may contain the following settings,
one per line. Unlike for the kernel command line, there is no limit in
the number of parameters for the save file
lang= menu language
kbmap= keyboard map
netmodule network card module (driver) to load
netmodparm parameters for network card module
dhcp whether to use dhcp (yes/no)
ip ip address (if dhcp not set)
netmask netmask (if dhcp not set)
port UDP port (default: 9000)
disk partition or disk to copy (for example /dev/hda)
umode snd for sender, rcv for receiver
compr compression mode (gz, lzop or none)
udpcparam additional parameter to pass to udpsender/udpreceiver
You may also use the online cast-o-matic tool to build an image:
http://udpcast.linux.lu/cast-o-matic/
A few words about an added feature I would like to
have :
I would like to have several process waiting on my linux server ready to
backup several hosts in their owns "file.img". That implies at least two
things :
The possibility to generate a unique file name for each different client
... or, alternatively, you may use a different UDP port for each
client type, and have udp-receivers listening for each client type,
each bound to their own file.
(One approach would be to send the mac address from
the client and to use
it with a time stamp on the server).
IP addresses might be easyer to implement (... and a one-to-one
mapping between Mac and IP may easily be set up by using a static DHCP
config)
The possibility for the receiver to be split in a
daemon part that never
quits and a child process to be spawned for each client.
Could be encapsulated into a while loop in a shell script.
#!/bin/sh
while : ; do
./udp-receiver -p 9002 -f client-9002.img --nokbd
mv client-9002.img client-9002-`date +%Y%m%d-%H%M%S`.img
done
The date command helps to make the file names unique, in order not to
overwrite earlyer transmissions.
For that part
maybe it could be easier to use in the middle an http server and a cgi
script.
Yes, you could make a CGI script which would start an udp-receiver (or
even a sender) in the background, and then return. The --nokbd option
may be helpful here, in order to prevent udp-receiver (or sender) to
become confused by the absence of a keyboard.
Regards,
Alain
6638
days inactive
6640
days old
1 comments
2 participants
participants (2)
-
Alain Knaff -
Bernard Chatin