Hardy Client fails to connect to standalone Landscape appliance
	Part X. Debian (sometimes also Ubuntu)

Hardy Client fails to connect to standalone Landscape appliance

Jurjen Bokma

September 2009

Success!

We've got a Landscape appliance running, but the clients fail to connect to it. Here is what I did:

Procedure 60. The failing connect of a client

Add the Landscape keys to the Apt keyring
On a newly installed Hardy, with /etc/apt/sources.list containing:
```
  deb http://landscape.canonical.com/packages/hardy ./
	
```
, we add the Landscape keys to the Apt keyring:
gpg --keyserver-options http-proxy --keyserver keyserver.ubuntu.com --recv-key C605E80D gpg --armor --export C605E80D | sudo apt-key add -
This action has a largely cosmetic purpose, as the landscape-client version is already from landscape.canonical.com:
apt-cache policy landscape-client landscape-client: Installed: 1.0.23-0ubuntu0.8.04 Candidate: 1.0.23-0ubuntu0.8.04 Version table: *** 1.0.23-0ubuntu0.8.04 0 500 http://landscape.canonical.com ./ Packages 100 /var/lib/dpkg/status 0.1 0 500 http://osis.service.rug.nl hardy/main Packages
Configure the Landscape client
Now the manual says to run sudo landscape-config --computer-title "My Web Server" --import https://<landscape server name>/config/bootstrap.conf but since the --import option seems to be missing in the client, we manually import the bootstrap.conf first and then use it:
wget https://landscape.mydomain.com/config/bootstrap.conf --13:25:06-- https://landscape.mydomain.com/config/bootstrap.conf <snip> 13:25:06 (21.57 MB/s) - `bootstrap.conf' saved [2293/2293] sudo landscape-config --computer-title $(hostname -f) -c bootstrap.conf --script-users nobody,landscape,root --silent * Stopping landscape-client daemon [ OK ] * Starting the landscape-client daemon [ OK ] Please wait... Error occurred contacting Landscape Client. Is it running?
Well, ps says it is:
root 8459 0.0 0.3 13408 7156 ? S 13:27 0:00 /usr/bin/python /usr/bin/landscape-client --daemon --pid-file /var/run/landscape-client.pid 112 8460 2.5 0.6 27124 12648 ? S 13:27 0:05 /usr/bin/python /usr/bin/landscape-broker --ignore-sigint --quiet 112 8462 2.3 0.5 30252 10332 ? S 13:27 0:04 /usr/bin/python /usr/bin/landscape-monitor --ignore-sigint --quiet root 8464 2.3 0.4 30212 10228 ? S 13:27 0:04 /usr/bin/python /usr/bin/landscape-manager --ignore-sigint --quiet
Running landscape-client with stdout to TTY
Because we don't understand the output in /var/log/landscape, we run the landscape-client without the --daemon option:
/etc/init.d/landscape-client stop sudo /usr/bin/python /usr/bin/landscape-client --pid-file /var/run/landscape-client.pid
Re-running landscape-config
Now when we run landscape-config again, we get:
sudo landscape-config --computer-title $(hostname -f) --script-users nobody,landscape,root --silent * Stopping landscape-client daemon [ OK ] * Starting the landscape-client daemon 2009-09-03 15:37:29,460 ERROR [MainThread] ERROR: The following daemons are already running: landscape-broker, landscape-monitor, landscape-manager [fail] Please wait... We were unable to contact the server. Your internet connection may be down. The landscape client will continue to try and contact the server periodically.
And the landscape-client process outputs:
<snip> 2009-09-03 15:37:31,986 INFO [MainThread] Queueing message to register with account 'standalone' without a password. 2009-09-03 15:37:31,987 INFO [MainThread] Starting urgent message exchange with https://landscape.mydomain.com/message-system. 2009-09-03 15:37:31,991 ERROR [Dummy-1 ] Error contacting the server at https://landscape.mydomain.com/message-system. Traceback (most recent call last): File "/usr/lib/python2.5/site-packages/landscape/broker/transport.py", line 47, in exchange curly, data = self._curl(spayload, computer_id, message_api) File "/usr/lib/python2.5/site-packages/landscape/broker/transport.py", line 34, in _curl headers=headers, cainfo=self._pubkey, curl=curl)) File "/usr/lib/python2.5/site-packages/landscape/lib/fetch.py", line 42, in fetch curl.perform() error: (77, 'Problem with the SSL CA cert (path? access rights?)') 2009-09-03 15:37:31,992 INFO [MainThread] Message exchange failed. 2009-09-03 15:37:31,992 INFO [MainThread] Message exchange completed in 0.01s. <snip>
Apache Warnings
Meanwhile inside the appliance, Apache in the error log says: [Thu Sep 03 08:28:20 2009] [warn] RSA server certificate CommonName (CN) `landscape.mydomain.com' does NOT match server name!?, which allegedly is just a warning about the hostname not agreeing with the certificate. The access log shows nothing.
OpenSSL output
As a side note, OpenSSL complained.
1. Local Issuer Certificates
  At first about local issuer certificates:
  openssl s_client connect landscape.mydomain.com:443 Verify return code: 20 (unable to get local issuer certificate)
2. Joining chain certificates
  My certificate is issued by an intermediate CA. Its certificate is not enough to link me to a trusted certificate. So instead of saying in /etc/landscape/server.conf:
```
ssl-certificate-chain-crt = /etc/ssl/certs/CybertrustEducationalCA.pem
            
```
  , I concatenated the CybertrustEducationalCA certificate and that of its issuer, GTECyberTrustGlobalRoot, put them in one file, and mentioned that file:
```
ssl-certificate-chain-crt = /etc/ssl/certs/ChainToRoot.pem
            
```
  . That gives us:
  openssl s_client -verify 3 -connect landscape.mydomain.com Verify return code: 19 (self signed certificate in certificate chain)
3. Actually verifying certificates with OpenSSL
  However when allowing OpenSSL to actually verify the certificates, we get:
  openssl s_client -CApath /etc/ssl/certs -connect landscape.mydomain.com:443 Verify return code: 0 (ok)

But alas, the error error: (77, 'Problem with the SSL CA cert (path? access rights?)') remains. So if at first you don't succeed, call in an airstrike. I mailed the experts at Ubuntu. Just for clarity, I have three certificates, one for my server, which we will call myserver.pem, and two public ones, for the educational branch of Globalsign: sureserverEDU.pem and its root certificate: ct_root.pem. Of course there's also a keyfile myserver.key paired with the myserver.pem. They match, as you will see. I went about thusly:

Try with just the server certificate
In /etc/landscape/server.conf on the appliance host, there is:
```
ssl-certificate-key = /etc/ssl/certs/myserver.key
ssl-certificate-crt = /etc/ssl/certs/myserver.pem
	
```
After reconfiguring the appliance and waiting for it to comu online, the landscape client still gives the now familiar libcurl error 77: Problem with reading the SSL CA cert (path? access rights?)
OpenSSL gives:
openssl s_client -connect landscape.mydomain.com:443 CONNECTED(00000003) depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl verify error:num=27:certificate not trusted verify return:1 depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA --- Server certificate -----BEGIN CERTIFICATE----- <snip> -----END CERTIFICATE----- subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA --- No client certificate CA names sent --- SSL handshake has read 1739 bytes and written 316 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: EBB6D07E79F01E7A5D17E074D8D0E4E210B99C8A3145D7A972CC027421DCCE81 Session-ID-ctx: Master-Key: EA07E6DD78FA70E9E70F15C92574AE443FBC4D457B1C89BB4FFCD53AB7244E7D165C44C528847F2638E9F401A32DD3FB Key-Arg : None Start Time: 1252057285 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) --- closed
With the intermediate certificate as ssl-certificate-chain-crt
That was to be expected. Now I follow tha manual, which says: “If your SSL Certificate needs a "Chain Certificate", for example GoDaddy issued ones, then fetch the SSL issuer's file and add the file as the ssl-certificate-chain-crt, this will be correctly configured inside Apache.” So /etc/landscape/server.conf looks like:
```
ssl-certificate-key = /etc/ssl/certs/myserver.key
ssl-certificate-crt = /etc/ssl/certs/myserver.pem

ssl-certificate-chain-crt = /etc/ssl/certs/sureserverEDU.pem
	
```
The Landscape client still gives the libcurl 77 error, but OpenSSL has changed:
openssl s_client -connect landscape.mydomain.com:443 CONNECTED(00000003) depth=1 /C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA verify error:num=20:unable to get local issuer certificate verify return:0 --- Certificate chain 0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA 1 s:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root --- Server certificate -----BEGIN CERTIFICATE----- <snip> -----END CERTIFICATE----- subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA --- No client certificate CA names sent --- SSL handshake has read 2836 bytes and written 316 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 0A2ECEC040EA71580975B999502F164509A139DD70B6AD5C15D171893758B830 Session-ID-ctx: Master-Key: 173E0403EF0D90C9DC32B1BD8B64A6890A3A5847E93391A34796B8ADEC22020A721F6BB85BEC5EFC5D7CF7244E54E9E2 Key-Arg : None Start Time: 1252058027 Timeout : 300 (sec) Verify return code: 20 (unable to get local issuer certificate) ---
With the root certificate as ssl-certificate-chain-crt
Because I gather from the airforce that this is actually the idea, I also try with the root certificate as ssl-certificate-chain-crt, so /etc/landscape/server.conf:
```
ssl-certificate-key = /etc/ssl/certs/myserver.key
ssl-certificate-crt = /etc/ssl/certs/myserver.pem

ssl-certificate-chain-crt = /etc/ssl/certs/ct_root.pem
	
```
Still error 77 from libcurl, but OpenSSL gives:
openssl s_client -connect landscape.mydomain.com:443 CONNECTED(00000003) depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl verify error:num=20:unable to get local issuer certificate verify return:1 depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl verify error:num=27:certificate not trusted verify return:1 depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl verify error:num=21:unable to verify the first certificate verify return:1 --- Certificate chain 0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA 1 s:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root --- Server certificate -----BEGIN CERTIFICATE----- <snip> -----END CERTIFICATE----- subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA --- No client certificate CA names sent --- SSL handshake has read 2348 bytes and written 316 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 2C9B5A5601E7C4DD353BD6A87C804C574B2A37D740291C875207DA6116363B6A Session-ID-ctx: Master-Key: 28EBCDB5CA4136CC11CD434177DA56F4BEE8855D3A999AD7C63EFB2A9FF6E197B43E4C6A73A4DD637C9193CDA06ACFEA Key-Arg : None Start Time: 1252058297 Timeout : 300 (sec) Verify return code: 21 (unable to verify the first certificate) ---
With the entire chain-to-root in ssl-certificate-chain-crt
I somewhat expected that. There is a root certificate now, but the server certificate cannot be linked to it because the intermediate certificate is unknown. So I follow the SSLCertificateChainFile directive documentation from Apache, and I concatenate the two certificates above mine, like this: cat sureserverEDU.pem ct_root.pem > ChainToRoot.pem, and make /etc/landscape/server.conf look like:
```
ssl-certificate-key = /etc/ssl/certs/myserver.key
ssl-certificate-crt = /etc/ssl/certs/myserver.pem

ssl-certificate-chain-crt = /etc/ssl/certs/ChainToRoot.pem
	
```
Still the 77 error from libcurl, but OpenSSL has changed again:
openssl s_client -connect landscape.mydomain.com:443 CONNECTED(00000003) depth=2 /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root verify error:num=19:self signed certificate in certificate chain verify return:0 --- Certificate chain 0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA 1 s:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root 2 s:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root --- Server certificate -----BEGIN CERTIFICATE----- <snip> -----END CERTIFICATE----- subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA --- No client certificate CA names sent --- SSL handshake has read 3445 bytes and written 316 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 6FF06A3A274167A58E01FC07D57A088382FDB5F9BA9B9549714AA043FF7C9E0F Session-ID-ctx: Master-Key: B3E771BD886D070F9C51C705D47898C943B9490C3114C57804DFBD18CB40511792A1290B02025391F78CD76BDBD758B3 Key-Arg : None Start Time: 1252058703 Timeout : 300 (sec) Verify return code: 19 (self signed certificate in certificate chain) --- closed
One more OpenSSL
This leads me to believe that the problem is that the CA certificate is not trusted. So I explicitly tell OpenSSL to trust all the certificates in /etc/ssl/certs (without putting any certs there that weren't there already):
openssl s_client -CApath /etc/ssl/certs -connect landscape.mydomain.com:443 CONNECTED(00000003) depth=2 /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root verify return:1 depth=1 /C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA verify return:1 depth=0 /C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl verify return:1 --- Certificate chain 0 s:/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl i:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA 1 s:/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root 2 s:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root --- Server certificate -----BEGIN CERTIFICATE----- <snip> -----END CERTIFICATE----- subject=/C=NL/ST=Groningen/L=Groningen/O=University of Groningen/OU=CIT/CN=landscape.mydomain.com/emailAddress=j.bokma@rug.nl issuer=/C=BE/O=Cybertrust/OU=Educational CA/CN=Cybertrust Educational CA --- No client certificate CA names sent --- SSL handshake has read 3445 bytes and written 316 bytes --- New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 1024 bit Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA Session-ID: 816ED083BEB198D711B0E0F5077482970B1A2DD754389BDDBC7900F05A08BEA5 Session-ID-ctx: Master-Key: 2F6668BC08B641FF93C98226BB4B1A4025487DF1750A0A6E9662703AD608A4B83776A16123BEE5F9051E7756E1B741EC Key-Arg : None Start Time: 1252061451 Timeout : 300 (sec) Verify return code: 0 (ok) ---

So from the above results, and from the StandAloneGuide_SSLCertificatesGuide.pdf I got with Landscape, which says:“configure the Landscape server and each client to accept your new CA”, in the case of self-signed certificates, but doesn't as far as I see instruct how to configure the client to accept that CA, I draw a tentative conclusion that:

the Landscape client doesn't accept my certificates because it doesn't trust the root CA,
the Landscape client doesn't trust the certificates in /etc/ssl/certs/ by default
there is a way to tell the Landscape client to trust either the /etc/ssl/certs/* certificates or some particular CA certificate (but I don't know it).

Success!

The airstrike hit the target. It appears that I was using the wrong options to landscape-config. The way to success is:

Use the right landscape-config options:

sudo landscape-config --computer-title $(hostname -f) --url https://landscape.mydomain.com/message-system --ping-url http://landscape.mydomain.com/ping --account-name standalone --silent * Stopping landscape-client daemon [ OK ] * Starting the landscape-client daemon [ OK ] Please wait... Error occurred contacting Landscape Client. Is it running?
Err... an error message. But the machine shows up in the Landscape GUI all the same.
Run landscape-client in the foreground just to make sure

sudo /etc/init.d/landscape-client stop sudo /usr/bin/python /usr/bin/landscape-client --pid-file /var/run/landscape-client.pid 2009-09-05 08:57:23,073 INFO [MainThread] Watchdog watching for daemons on 'system' bus. 2009-09-05 08:57:28,166 WARNING [MainThread] landscape-broker failed to respond to a ping. 2009-09-05 08:57:28,167 WARNING [MainThread] landscape-monitor failed to respond to a ping. 2009-09-05 08:57:28,168 WARNING [MainThread] landscape-manager failed to respond to a ping. 2009-09-05 08:57:31,775 INFO [MainThread] Broker started on 'system' bus with config /etc/landscape/client.conf 2009-09-05 08:57:31,779 INFO [MainThread] Manager started on 'system' bus with config /etc/landscape/client.conf 2009-09-05 08:57:31,781 INFO [MainThread] Registering plugin landscape.manager.processkiller.ProcessKiller. 2009-09-05 08:57:31,781 INFO [MainThread] Registering plugin landscape.manager.packagemanager.PackageManager. 2009-09-05 08:57:31,782 INFO [MainThread] Registering plugin landscape.manager.usermanager.UserManager. 2009-09-05 08:57:31,782 INFO [MainThread] Registering plugin landscape.manager.shutdownmanager.ShutdownManager. 2009-09-05 08:57:31,788 INFO [MainThread] Monitor started on 'system' bus with config /etc/landscape/client.conf 2009-09-05 08:57:31,789 INFO [MainThread] Registering plugin landscape.monitor.activeprocessinfo.ActiveProcessInfo. 2009-09-05 08:57:31,789 INFO [MainThread] Registering plugin landscape.monitor.computerinfo.ComputerInfo. 2009-09-05 08:57:31,790 INFO [MainThread] Registering plugin landscape.monitor.hardwareinventory.HardwareInventory. 2009-09-05 08:57:31,790 INFO [MainThread] Registering plugin landscape.monitor.loadaverage.LoadAverage. 2009-09-05 08:57:31,790 INFO [MainThread] Registering plugin landscape.monitor.memoryinfo.MemoryInfo. 2009-09-05 08:57:31,790 INFO [MainThread] Registering plugin landscape.monitor.mountinfo.MountInfo. 2009-09-05 08:57:31,790 INFO [MainThread] Registering plugin landscape.monitor.processorinfo.ProcessorInfo. 2009-09-05 08:57:31,791 INFO [MainThread] Registering plugin landscape.monitor.temperature.Temperature. 2009-09-05 08:57:31,791 INFO [MainThread] Registering plugin landscape.monitor.packagemonitor.PackageMonitor. 2009-09-05 08:57:31,792 INFO [MainThread] Registering plugin landscape.monitor.usermonitor.UserMonitor. 2009-09-05 08:57:35,964 INFO [MainThread] Starting urgent message exchange with https://landscape.mydomain.com/message-system. 2009-09-05 08:57:36,065 INFO [MainThread] Monitor stopped on 'system' bus with config /etc/landscape/client.conf 2009-09-05 08:57:36,075 INFO [MainThread] Manager stopped on 'system' bus with config /etc/landscape/client.conf 2009-09-05 08:57:36,266 INFO [Dummy-1 ] Sent 157 bytes and received 146 bytes in 0.30s. 2009-09-05 08:57:36,270 INFO [MainThread] Switching to normal exchange mode. 2009-09-05 08:57:36,270 INFO [MainThread] Accepted types changed: +register +register-cloud-vm test 2009-09-05 08:57:36,276 INFO [MainThread] Queueing message to register with account 'standalone' without a password. 2009-09-05 08:57:36,277 INFO [MainThread] Starting message exchange with https://landscape.mydomain.com/message-system. 2009-09-05 08:57:36,287 INFO [MainThread] Message exchange completed in 0.32s. 2009-09-05 08:57:36,912 INFO [Dummy-1 ] Sent 342 bytes and received 179 bytes in 0.63s. 2009-09-05 08:57:36,915 INFO [MainThread] Using new secure-id ending with YPzk1Z91zz for account standalone. 2009-09-05 08:57:36,921 INFO [MainThread] Message exchange completed in 0.64s.
So no error 77 any more. And we can accept the client in the GUI.


Partman-auto recognizing free space properly		Logging in on the Landscape Appliance