getltscfg for individual thin clients

Frantisek Hanzlik franta at hanzlici.cz
Mon May 19 01:58:55 UTC 2008


Warren Togami wrote:
> Frantisek Hanzlik wrote:
>> Hello,
>>
>> in little connection with lp_server, I forgot one thing - F9 ltsp-1.5.7
>> scripts nowhere calls 'getltscfg -n' for thin clients individual
>> settings, thus only [default] section of lts.conf is processed - it
>> is by calling 'getltscfg -a' at beginning of "ltsp_config" script
>> (which is then included in several others scripts).
>>
>> My workaround about this was put "getltscfg -n" command at start
>> of "ltsp-init-common" script:
>>
>> --- ltsp-init-common.OLD 2008-05-07 23:13:50.000000000 +0200
>> +++ ltsp-init-common 2008-05-19 03:13:56.000000000 +0200
>> @@ -7,6 +7,7 @@
>> msg="$1"
>> logger -p user.warning -t ltsp-client "warning: $msg"
>> }
>> +getltscfg -n # get client specific settings
>>
>> start_sound() {
>> if boolean_is_true "$SOUND" ; then
>>
>
> Grepping through ltsp-trunk I don't see Debian doing anything like this.
> How is Debian's LTSP using individual client settings?
>
> Warren Togami
> wtogami at redhat.com
>
> _______________________________________________
> K12Linux-devel-list mailing list
> K12Linux-devel-list at redhat.com
> https://www.redhat.com/mailman/listinfo/k12linux-devel-list
>

Sorry for my shortage, after looking to getltscfg.c source, I see
when getltscfg is called with "-n" option, then output only station
specific settings. And when is called with "-a", then getltscfg output
ALL: station specific and these from [default] too.
Thus calling getltscfg with -a is quite sufficient.

This my mistake was comming from bad named client-specific
sections, grrr.

Franta H




More information about the K12Linux-devel-list mailing list