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.
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