The installation program should be able to read answers to all questions it will ask from a file. This would be of use in at least the following cases: * People that want to install a large number of vsmagents in a automated way could use it. * We could use it internally for testing, to install and run a ThinLinc server after each nightly build.
Åstrand proposes the name "KickLinc" :-)
Incomplete list of things that needs to be done manually if skipping tl-setup: * Create symlink: # ln -sf sshd /etc/pam.d/thinlinc * Create symlink to suitable Python binary # ln -sf python /usr/bin/python-thinlinc * Create symlink: # ln -sf /opt/thinlinc/libexec/thinlinc-login /usr/bin/thinlinc-login * Make sure dependency packages are installed, that a SSH daemon is running, and that suitable ports in the firewall are open. * If special printer queues are to be used, create them by running: # /opt/thinlinc/libexec/add_thinlocal_printer.sh # /opt/thinlinc/libexec/add_nearest_printer.sh * If using SELinux, run. # /opt/thinlinc/share/selinux/install. * Start services at boot: # /opt/thinlinc/libexec/install_service vsmserver 99 10 # /opt/thinlinc/libexec/install_service vsmagent 98 10 # /opt/thinlinc/libexec/install_service tlwebadm 99 10 * Set admin email: # tl-config /vsmserver/admin_email=myemail@myorganisation * Set password for the web interface: # tl-config /tlwebadm/password=`/opt/thinlinc/sbin/tl-gen-auth mypassword` If tlclient.cgi is to be used: * Make sure that web server with TLS support is installed * Set ownership of /var/log/tlclient.cgi.log to the user running the web server * For Apache, copy /opt/thinlinc/share/browser_client/thinlinc.conf to the httpd conf.d directory, typically located below /etc. Finally: * Indicate that the configuration is finished: # read thinlinc version < /opt/thinlinc/etc/thinlinc-release # /opt/thinlinc/bin/tl-config /vsm/setup_completed=${version}
The Sun Ray "utsetup" can apparently be automated with a response file.
While an automated text-mode setup looks fairly straight-forward, having an automated PyGTK-based setup will be much harder unless we solve bug 4232 to separate the questions from the actions.
Committed as r29868-r29878.
Even without arguments you get a bunch of these in the log: > 2015-02-26 09:30:07,347: No answer given for key accept-eula. > 2015-02-26 09:30:08,527: No answer given for key server-type. Is that really necessary?
(In reply to comment #8) > Even without arguments you get a bunch of these in the log: > > > 2015-02-26 09:30:07,347: No answer given for key accept-eula. > > 2015-02-26 09:30:08,527: No answer given for key server-type. > > Is that really necessary? Fixed in r30059.
When running using -g option without argument i get following output: [root@dhcp-253-34 conf.d]# tl-setup -g Usage: tl-setup [options] tl-setup: error: -g option requires an argument You can restart this wizard by running "ThinLinc Setup" from the menu, or executing /opt/thinlinc/sbin/tl-setup. The two last lines does not belong here...
After thoroughly testing here are the summarized issues I found: - Errors such as "ERROR: No answer given for.." is written to stdout instead of stderr - Default behavior when running tl-setup with answer file that has a missing config key is to "interactivly" ask. This seems wrong when this "interactive" mode is not wanted when its used for automated deployment (puppet etc). The default should be abort so the error can get caught by the non-interactive executor... - Choosing 'no' as answer for installation of essentials is ignored and wizard will continue installation of essential packages such as xauth in my case. - Running tl-setup -a non-existing-file will give following trace: ERROR:root:Traceback (most recent call last): ERROR:root: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 572, in <module> ERROR:root: ooO0OO ( ) ERROR:root: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 391, in ooO0OO ERROR:root: tlsetup . parse_answers_file ( OOoOO0o0o0 . answers_file ) ERROR:root: File "/opt/thinlinc/modules/thinlinc/tlsetup/__init__.py", line 67, in parse_answers_file ERROR:root: for O0OoOoo00o in iiIIIIi1i1 . get_parameters ( '/' ) : ERROR:root:AttributeError: 'NoneType' object has no attribute 'get_parameters' - tl-setup -g existing-file, will blindly overwrite existing configuration file. Should probably ask user if overwrite or merge new "questions" available into existing file.
(In reply to comment #10) > When running using -g option without argument i get following output: > > [root@dhcp-253-34 conf.d]# tl-setup -g > Usage: tl-setup [options] > > tl-setup: error: -g option requires an argument > > > You can restart this wizard by running "ThinLinc Setup" from the menu, > or executing /opt/thinlinc/sbin/tl-setup. > > The two last lines does not belong here... This seems to apply to all exit codes which is not 0 >> Using answer accept-eula=no from answer file You can restart this wizard by running "ThinLinc Setup" from the menu, or executing /opt/thinlinc/sbin/tl-setup.
Apparmor was forgotten in commit r29874 which adds use of answers.
(In reply to comment #13) > Apparmor was forgotten in commit r29874 which adds use of answers. Fixed in commit r30220.
Update our internal Thinlinc puppet module to use a answer file for deploying ThinLinc. Works as expected tested using Ubuntu 14.04.
(In reply to comment #11) > After thoroughly testing here are the summarized issues I found: > > - Errors such as "ERROR: No answer given for.." is written to stdout > instead of stderr r30241. > - Default behavior when running tl-setup with answer file that has a > missing config key is to "interactivly" ask. This seems wrong when > this "interactive" mode is not wanted when its used for automated > deployment (puppet etc). The default should be abort so the error > can get caught by the non-interactive executor... As per discussions outside of Bugzilla, we'll leave this as-is for now. > - Choosing 'no' as answer for installation of essentials is ignored > and wizard will continue installation of essential packages such > as xauth in my case. r30243. > - Running tl-setup -a non-existing-file will give following trace: > > ERROR:root:Traceback (most recent call last): > ERROR:root: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 572, in > <module> > ERROR:root: ooO0OO ( ) > ERROR:root: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 391, in > ooO0OO > ERROR:root: tlsetup . parse_answers_file ( OOoOO0o0o0 . answers_file ) > ERROR:root: File "/opt/thinlinc/modules/thinlinc/tlsetup/__init__.py", > line 67, in parse_answers_file > ERROR:root: for O0OoOoo00o in iiIIIIi1i1 . get_parameters ( '/' ) : > ERROR:root:AttributeError: 'NoneType' object has no attribute > 'get_parameters' r30242. > - tl-setup -g existing-file, will blindly overwrite existing > configuration file. Should probably ask user if overwrite or > merge new "questions" available into existing file. I've discussed this with Henrik, won't take actions. If we could get tl-setup to spit out a new answer file after a successful run (bug 5391), merging would be as easy as run tl-setup with old file (with missing-answer=ask), answer new questions and get a new file.
(In reply to comment #16) Tested using server build 4726: > (In reply to comment #11) > > After thoroughly testing here are the summarized issues I found: > > > > - Errors such as "ERROR: No answer given for.." is written to stdout > > instead of stderr > > r30241. > Works as expected > > > - Choosing 'no' as answer for installation of essentials is ignored > > and wizard will continue installation of essential packages such > > as xauth in my case. > > r30243. > Works as expected > > - Running tl-setup -a non-existing-file will give following trace: > > > > ERROR:root:Traceback (most recent call last): > > ERROR:root: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 572, in > > <module> > > ERROR:root: ooO0OO ( ) > > ERROR:root: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 391, in > > ooO0OO > > ERROR:root: tlsetup . parse_answers_file ( OOoOO0o0o0 . answers_file ) > > ERROR:root: File "/opt/thinlinc/modules/thinlinc/tlsetup/__init__.py", > > line 67, in parse_answers_file > > ERROR:root: for O0OoOoo00o in iiIIIIi1i1 . get_parameters ( '/' ) : > > ERROR:root:AttributeError: 'NoneType' object has no attribute > > 'get_parameters' > > r30242. > Works as expected
- Issue in comment #10 is still a problem. - If runnning tl-setup with a template and only set answer for EULA to yes to get the process continue. The examples in template are used as answers. SELinux ======= This system is using the SELinux access control system. A ThinLinc module needs to be loaded for ThinLinc to operate correctly in this environment. Would you like to compile and install the ThinLinc SELinux module? >> Using answer setup-selinux=yes|no from answer file It's not clear what the defaults are, maybe the template file should comment out the example answers in the template... In SELinux example the answer is not true and it will be skipped and for the email address the example email is used...
(In reply to comment #18) > - Issue in comment #10 is still a problem. I'm leaning towards wontfix for this particular issue. I don't see it being harmful or incorrect, and removing it from a few edge cases seems like lots of work for small improvements. > - If runnning tl-setup with a template and only set answer > for EULA to yes to get the process continue. The examples > in template are used as answers. > > SELinux > ======= > > This system is using the SELinux access control system. A ThinLinc > module needs to be loaded for ThinLinc to operate correctly in this > environment. Would you like to compile and install the ThinLinc > SELinux module? > > >> Using answer setup-selinux=yes|no from answer file > > It's not clear what the defaults are, maybe the template file should > comment out the example answers in the template... In SELinux example > the answer is not true and it will be skipped and for the email address > the example email is used... w.r.t. having these as comments, I've had the same thought myself, but it got lost somewhere along the way. Fixed in r30247.
Retested using build 4727 and verified that automatic (puppet) and manual deployment using answer file works as expected. Everything looks good, closing.
tl-setup traceback while running on rhel5 which uses python-2.4.3-56.el5: Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: Traceback (most recent call last): Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: File "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 41, in ? Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: from thinlinc import tlsetup Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: File "/opt/thinlinc/modules/thinlinc/tlsetup/__init__.py", line 78 Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: with open ( f , 'w' ) as i1iIIi1 : Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: ^ Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: SyntaxError: invalid syntax
(In reply to comment #21) > tl-setup traceback while running on rhel5 which uses python-2.4.3-56.el5: > > Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: Traceback > (most recent call last): > Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: File > "/opt/thinlinc/sbin/../libexec/tl-setup.py", line 41, in ? > Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: from > thinlinc import tlsetup > Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: File > "/opt/thinlinc/modules/thinlinc/tlsetup/__init__.py", line 78 > Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: with > open ( f , 'w' ) as i1iIIi1 : > Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: > ^ > Notice: /Stage[main]/Thinlinc::Install/Exec[run-tl-setup]/returns: SyntaxError: > invalid syntax Fixed in r30263. An autotest to warn about usage of these constructs was added in r30264, and thanks to these, I found that tl-notify was also using the same constructs. I fixed that issue in r30265. The tester should make sure tl-notify still works.
> > Fixed in r30263. > > An autotest to warn about usage of these constructs was added in r30264, and > thanks to these, I found that tl-notify was also using the same constructs. I > fixed that issue in r30265. > > The tester should make sure tl-notify still works. Using build 4737 i verified both tl-setup and tl-notify functionality. Closing.
