From: John H. <lt...@pr...> - 2012-12-21 01:26:56
|
On 12/20/2012 8:11 PM, John Hupp wrote: > On 12/20/2012 1:32 PM, Andreas Schamanek wrote: >> Hi John, >> >> I don't know much about LTSP but I know _sed_ well enough to be able >> to provide hopefully helpful answers. >> >> On Thu, 20 Dec 2012, at 10:43, John Hupp wrote: >> >>>>> I'm using a client boot script at /usr/share/ltsp/init-ltsp.d/50-apcupsd >>>>> with sed to modify a configuration file. The script: >>>>> >>>>> sed -i \ >>>>> -e 's/UPSCABLE usb/UPSCABLE ether/' \ >>>>> -e 's/UPSTYPE usb/UPSTYPE net/' \ >>>>> -e 's/DEVICE/DEVICE Lubuntu1:3551/' \ >>>>> -e 's/TIMEOUT 105/TIMEOUT 60/' \ >>>>> -e 's/NETSERVER on/NETSERVER off/' \ >>>>> -e 's/NISIP 0.0.0.0/NISIP 127.0.0.1/' \ >>>>> /etc/apcupsd/apcupsd.conf >> You said this worked. And it should. Note, though that sed "rules" >> starting with 's/' are substitutions. If what is to be substituted >> does not exist in the first place, you'll never get the results you >> want. E.g., if the TIMEOUT in the original file is not 105, the result >> will never be 60. This line could be written as >> >> -e 's/TIMEOUT [1-9][0-9]*/TIMEOUT 60/' \ >> >> then TIMEOUT 0 is untouched, but any other integer value is replaced >> with 60. >> >>>>> It all works fine except for this substitution: >>>>> -e 's/DEVICE/DEVICE Lubuntu1:3551/' >>>>> >>>>> It takes this line: >>>>> DEVICE >>>>> and replaces it with this: >>>>> DEVICE Lubuntu1:3551 Lubuntu1:3551 >>>>> >>>>> However, if I run the same script on the server, it does not >>>>> produce the duplicate "Lubuntu1:3551". Does anyone know why? >> There are only 2 possible explanations: >> >> A) The script runs twice. >> B) The original line was not "DEVICE" but "DEVICE Lubuntu1:3551" >> (maybe because another script changed it). >> >> 's/DEVICE/DEVICE Lubuntu1:3551/' replaces the 1st "DEVICE" with >> "DEVICE Lubuntu1:3551". If you apply this twice you get "DEVICE >> Lubuntu1:3551 Lubuntu1:3551" >> >>>>> Seeking a work-around, I added an /etc/apcupsd/apcupsd_slave.conf file >>>>> which was already modified with the parameters I want clients to boot >>>>> with. Then I edited /usr/share/ltsp/init-ltsp.d/50-apcupsd to remove the >>>>> sed command and added: >>>>> >>>>> cp /etc/apcupsd/apcupsd_slave.conf /etc/apcupsd/apcupsd.conf >>>>> >>>>> But this does not seem to execute. >> Double check that files are indeed where they should be >> (server-client-wise). This should execute. Maybe add a logger >> statement to debug. >> >>>>> local session xterminal and run: >>>>> $ su root cp /etc/apcupsd/apcupsd_slave.conf /etc/apcupsd/apcupsd.conf >>>>> it returns: >>>>> /bin/cp: cannot execute binary file >> I guess this should be >> >> su root -c cp ... >> >>>> Someone points out that with the sed command, I would get the >>>> duplicate result I report if the script ran twice. >> Ah, so someone said it before :) >> >>>> Does that trigger any thoughts? >> I don't have the same setup. But I'd check what is in >> /opt/ltsp/i386/etc/apcupsd/apcupsd.conf >> >>> Someone else wondered if the colon in the replacement expression >>> needed to be escaped. >> Definitely no. >> >>> But I still have the thinnest possible understanding of the finer >>> points of sed and the substitution syntax, especially about escaping >>> special characters. >> Your script is fine. There's a lot that needs to be escaped in general >> terms but no in your specific case. >> >>> I don't even know if the backslash would go before or after the >>> colon! >> As I said, do not touch the colon. Backslashes are required at the end >> of the lines, because the whole command is made of multiple lines. The >> Backslashes are actually for Bash (or whatever shell) not for sed. >> >>> But I had wondered about the possible effect of that colon myself. >>> To test that idea, I replaced the colon with a space: >>> sed -e 's/DEVICE/DEVICE Lubuntu1 3551/' >>> Now on the LTSP client, the resulting line is: >>> DEVICE Lubuntu1:3551 Lubuntu1 3551 >> That's interesting. If this was the result then the script with >> the "missing"/replaced colon ran first. Another substitution took >> place afterwards. This excludes the scenario "A" mentioned above! >> >>> I don't know what the syntax means, but someone also suggested the >>> following: >>> >>> sed -e 's/DEVICE$/DEVICE Lubuntu1:3551/' >>> >>> And that had no effect whatsoever. The result was still "DEVICE >>> Lubuntu1:3551 Lubuntu1:3551". >> The suggestion is good. It replaces "DEVICE" only if it is the last >> word on the line. It did not help you because, apparently, your script >> finds "DEVICE" and only "DEVICE" and replaces it correctly and as >> intended. There must be another script that messes it all up. >> >>> Does LTSP use something like a writable overlay filesystem? >> AFAIK, yes, but someone with a better understand should fill you in on >> this. >> >> HTH, > > Thanks for giving this a thorough look. I can verify now that the > script is doing its job. Something else is overwriting the file again > after that. > > Given the nature of the overwrite, I have to think that I must have > set in place whatever is doing the damage. Probably some earlier > troubleshooting attempt which I did not record and have now > forgotten. If I can't remember then I suppose I'll have to look > through every location where something can start from in an LTSP > client bootup. > Although as I think just a moment more about that (late at night), since I am using LTSP-PNP and the network boot image is built from my regular environment and not a chroot, and since my regular-environment /etc/apcupsd/apcupsd.conf is not being modified by anything during server boot, that narrows down the cause to special mechanisms that *only* function for client boots (like a /usr/share/ltsp/init-ltsp.d/ script or something put into play by lts.conf). Does that sound true? |