@Tom-Elliott I’ve made a test with storage1 node as master and it is the same. It keeps on looking at default storage group. I’m going to update code as you suggested.

@Frank The only thing is that storage1 node wasn’t market as master. Can it be the reason? The image is associated to storage1 group

@Tom-Elliott the image IS in the storage1 node. I can see it on /images directory

Hi @Tom-Elliott , I’m not sure I’ve explained myself.
We have two storage groups: default and storage1, each composed by a single node.
If I upload an image to storage1, I can. When but I try to download it, I get a message saying I must upload it first. I’ve realized it is searching in default storage group, not storage1.

Hi all,
we have ubuntu 14.04 servers with fog 1.2 revision 6509
We have realized that you can upload an image to a repository different from default, but after that, you you try to deploy it, you get an error message that you must upload it first. That is because it look it up on default storage node. So if you copy it there, it works.
Have you notice that?
Thanks for your help.

Thanks @Wolfbane8653 for your suggestion. I’m going to do it.

I guess you know it, but just as a remember:

svn up

Updating ‘.’:
svn: E000111: Unable to connect to a repository at URL ‘https://svn.code.sf.net/p/freeghost/code/trunk’
svn: E000111: Error running context: Connection refused

Today I have installed svn 3783 which uses client 0.9.4 and the service error has gone.
Another issue that remains is in host login history, where you can read logins/logouts but not username info.

Hi,
which fog svn 3761 and client version 0.9.2 I have running in ubuntu 14.04 LTS I have found a couple of issue:

Users login history does not seem to be tracked
Hostname service outputs this message:
Service ERROR: Index and length must refer to a location within the string.
Parameter name: length

Thanks for your help.

Mod corrected info.

@Jbob I’m here to make tests if you can.

Hi @Jbob . Any news?
Remember I can do any tests if you need to.
Regards.

Thanks @Jbob
I take note of your advise
Tell me if you need to make some kind of test.

Regards.

This is an issue discussed with Tom Elliot some days ago and some revisions ago.
When trying to join to samba NT domain client shows an error:

17/06/2015 13:31 HostnameChanger Checking Hostname
 17/06/2015 13:31 HostnameChanger Hostname is correct
 17/06/2015 13:31 HostnameChanger Registering host with active directory
 17/06/2015 13:31 HostnameChanger Unknown Return Code:  50
 17/06/2015 13:31 HostnameChanger Activing host with product key
 17/06/2015 13:31 HostnameChanger ERROR: Windows activation disabled

It seems related to lpMachineAccoutOU which was null in previous releases when it was not specified and now it is blank:

06/12/2015 07:54:25:520 NetpProvisionComputerAccount:
06/12/2015 07:54:25:520 	lpDomain: UPC-CT
06/12/2015 07:54:25:520 	lpMachineName: HPSB
06/12/2015 07:54:25:520 	lpMachineAccountOU: 
06/12/2015 07:54:25:520 	lpDcName: RADI
06/12/2015 07:54:25:520 	lpDnsHostName: (NULL)
06/12/2015 07:54:25:520 	lpMachinePassword: (null)
06/12/2015 07:54:25:520 	lpAccount: UPC-CT\fog.domini
06/12/2015 07:54:25:520 	lpPassword: (non-null)
06/12/2015 07:54:25:520 	dwJoinOptions: 0x3
06/12/2015 07:54:25:520 	dwOptions: 0x40000003

I was told this would be fixed but no news at the moment.

Thanks for your help.

Frank

I have reinstalled all fog files in server and fog client in client machine and logs are the same.
I guess public key is at “/var/www/fog/management/other/ssl/srvpublic.key” in server and at “\program files\FOG\tmp” in client machine, and I have checked they are equal.
I have found private key in server at “/opt/fog/snapins/ssl/.srvprivate.key”. Is that where is supposed to be?
I don’t know how go on from here!

Ok, that sounds good:)
How do I do that? Just removing /var/www/fog/management/other/ssl/srvpublic.key and invoking “installfog.sh” again?

I have done this:

• removed /var/www/fog/management/other/ssl and /opt/fog/snapins/ssl
• uninstalled fog client on client machine
• be sure no fog files remain on client machine
• install fog client and reboot
• on server, directory /var/www/fog/management/other/ssl with srvpublic.key file has been created again
• on client machine logs show this:

05/05/2015 17:25 RegistryHandler 32 bit registry detected

--------------------------------Authentication--------------------------------

05/05/2015 17:25 Client-Info Version: 0.7.2
05/05/2015 17:25 CommunicationHandler URL: [url]http://172.16.1.43/fog/management/other/ssl/srvpublic.key[/url]
05/05/2015 17:25 CommunicationHandler ERROR: error:0906D06C:PEM routines:PEM_read_bio:no start line
05/05/2015 17:25 CommunicationHandler Failed to authenticate

So different. But what does this mean?

The same thing.
This is the GET line log before “Invalid host certificate”. Perhaps can show you something:
[05/May/2015:16:36:16 +0200] “GET /fog/management/index.php?sub=authorize&sym_key=8d951420a55d8b8f7d4845105b33cd8cfffaf3d2aca9f47cfef66585104cae607822811e2aaf93a55290577ca0918d743cf549eb5c1fa06e77d99f49a7378f96ee10f36df0fc36a7595b704b3712cb2d2f8412b18c4ceab1da1a290d42605d243d3c0c7df1487ce4b214a36e66e5dc44e3abdc22d773f1fa4e879b122968d1d27a7d80eb3c0ca636052cb2aaf5104c129c138c1662697ab9872e678e04178793b9abf5192b98ce105a6f08c87b8c51e530f9df4ea6d9d4f3e7b44489ebc73f15b3e4d50020bd05a8bfac2c17be9bd25b5cd6d16978daa7df6f0caa5ed53e2a6c5ba87cd9ce42a6b13d083318b5d8e59b06e5f1fba89e88ccd46f0d8b2b701621b5d486dfdf6043b70b4a96a4904dfdb13bb58880fe0b2b22df958a3859919778da9a1ca73d88f14c8b8ea0f795dfa2d9b43f0f24a2564c202ac204f29a44873068396dc3cd13e94f6f33dace7179cf4156d7dc591c7af3509eb4eac2bfe0e4622702e5c84a745702550c09179771b11d0740e954b16d58d8fdeab62a8b84e5fc02960d092982f0be0732d608b9996d47d8d60168298621802c8bdfd547829b5d688014fe54a51e47798bd3fa8c810e427b53121ec19a5281227344059edd8ef035ea85e2241c1c1adecb7bf09aae0bda90038336c80faefd72a243fadba53f94a20eddd27b41dbb1e870a835eb44e3aa983db3bdea17143373ff49587ccfd53e&mac=00:FF:EC:5A:67:35%7C00:0E:0C:5E:17:AE%7C%7C00:00:00:00:00:00:00:E0%7C00:00:00:00:00:00:00:E0%7C00:00:00:00:00:00:00:E0%7C00:00:00:00:00:00:00:E0&newService=1 HTTP/1.1” 200 403 “-” “-”

I’ve noticed that the “sym_key” changes in each service start.

Of course.Right now!

Excuse me Tom, any suggestion with this?

Thanks.

This is the complete auth log:

------------------------------------------------------------------------------ 
--------------------------------Authentication-------------------------------- 
------------------------------------------------------------------------------ 
 30/04/2015 13:28 Client-Info Version: 0.7.2 
 30/04/2015 13:28 CommunicationHandler URL: [url]http://172.16.1.43/fog/management/other/ssl/srvpublic.key[/url] 
 30/04/2015 13:29 CommunicationHandler URL: [url]http://172.16.1.43/fog/management/index.php?sub=authorize&sym_key=78feb292d19c52ec00f6ea87bce277632a47effa058ce85ee7971ae087e568f977f519a167c7cf18[/url]
d511673305644c426384999d8d65e22b336b2cfe99f01e3a9774339999c28dc84533e6467e8df819e6061e6597474eeeb9b94da
3a3e4cd907aecc8da0ac5db58040306eaecccd5b5339c46d3287e0cdf214c28517d336b39577909869fed0c25a1ca54f8a8d79d
ad237af9753800e69c54917f2ec65ff32468d800566df2151c614a499a5e42e6cf285f66a7b0388a6d9b7fc3507790638a58d32
f334fa652eb549efd6d9b503ba93e11c442f033363a8b8ffd39a791196a7ead4d71e270fd504f7f6a6b4f2173ac112511f980d0
7d2127d6b6ac3cca0997c977cf032e97b2a993427ba0e0ede7b86bc7c89b940274ccf520f8f3438d9bf196a196241157307c476
5de5be8a7c66a98d06d257003a3b0059feee12fbfaf3a13da042d126beb3b19da6438e2de7a64ddd297cf56080479c58120f959
85849abf841f7a670b735ab99b39ee4923fc104d61d7fb18366395ec3a6789bb79cee614a5e75b74a939fa7e8f0be94b0079fcd
3373122ec0b508feaff2e2cac0b21ea9e848bd9d2ae4387c1d9e1f8680a7ad870087bf551b007e5039e33ba5fa4b0eb1d661008
da661422b196664fa434379baeb79959eb3b2dbc79704cbebe678495d9a8dd495f10b8775e01b6a4c30ad4ef6402f0695276d6d
33d1635dcfabae647&mac=00:FF:EC:5A:67:35|00:0E:0C:5E:17:AE||00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:
E0|00:00:00:00:00:00:00:E0|00:00:00:00:00:00:00:E0&newService=1 
 30/04/2015 13:29 CommunicationHandler Response: Invalid host certificate 
 30/04/2015 13:29 CommunicationHandler Failed to authenticate