+1 This branch behaves as you mentioned in the merge description.
tried feeding bogus values into ping_interval to validate that dpkg-reconfigure crashes and doesn't write the config file if some bogus option values live in /etc/landscape/client.conf and get passed to landscape-config cmdline.
Couple questions:
[1] Since we just now got rid of the static landscape-config header values for log_level & data_path, should these default values be added into debian/landscape-client.templates and pull a db_get $PACKAGE/data_path * log_level to pass on the cmdline to landscape-config?
68 -log_level = info
69 -data_path = /var/lib/landscape/client
[2] Why not validate if REGISTRATION_PASSWORD is non-null too before attempting a registration? I know we've got he --ok-no-register flag set but do we already allow empty registration passwords for clients?
118 + if [ -n "$ACCOUNT_NAME" -a -n "$COMPUTER_TITLE" ]; then
+1 This branch behaves as you mentioned in the merge description.
tried feeding bogus values into ping_interval to validate that dpkg-reconfigure crashes and doesn't write the config file if some bogus option values live in /etc/landscape/ client. conf and get passed to landscape-config cmdline.
Couple questions: landscape- client. templates and pull a db_get $PACKAGE/data_path * log_level to pass on the cmdline to landscape-config?
[1] Since we just now got rid of the static landscape-config header values for log_level & data_path, should these default values be added into debian/
68 -log_level = info landscape/ client
69 -data_path = /var/lib/
[2] Why not validate if REGISTRATION_ PASSWORD is non-null too before attempting a registration? I know we've got he --ok-no-register flag set but do we already allow empty registration passwords for clients?
118 + if [ -n "$ACCOUNT_NAME" -a -n "$COMPUTER_TITLE" ]; then