@Tom-Elliott It was unable to find an acceptable C compiler on $Path

I think I remember seeing unnecessary dependancies being removed when I was upgrading the kernel, guess I should fix that!

@Tom-Elliott I can see the files in /tmp of udpcast, any test I can perform on those files?

@Tom-Elliott Nope, it’s just your basic fstab.

I did update the kernel yesterday, possibly related?

Updated main server (ubuntu 15.10) to latest revision and it worked fine.

Tried to update storage node (CentOS 7) to latest revision and it failed at configuring UDP Cast.

The error log is empty, so no luck there.

I have 11 apache processes running right now, I’m fairly certain it’s normal behavior. Load is under 0.5% total.

Are they trying to UEFI network boot?

@Sebastian-Roth Sounds good yeah, I’d love to help out

@Tom-Elliott I can reproduce his issue by enabling FOG_FTP_IMAGE_SIZE and then going to the image listing.

[Wed Mar 16 10:39:57.982297 2016] [:error] [pid 21773] [client 192.168.1.31:53632] PHP Fatal error: Call to a member function get() on null in /var/www/fog/lib/pages/imagemanagementpage.class.php on line 70, referer: http://192.168.1.154/fog/management/index.php?node=about&sub=settings

@arnaudrigole I’m not experienced with AD, so I had to use some googlefu and it seems like this is an issue with AD mapping unix users.

Check out this link on what to try: http://blogs.msdn.com/b/sfu/archive/2007/04/19/mounting-nfs-share-on-nfs-client.aspx

@Wayne-Workman My idea would be to ONLY continue when it detects Unlicensed, so burning keys won’t be possible in that scenario. So if anything that isn’t “Unlicensed” is detected the script will not continue to try and use the key, it will only continue of Unlicensed.

@arnaudrigole Seems like you don’t have an export for /FOG/Images only for /FOG. Can you mount /FOG over NFS?

@arnaudrigole Do this on your linux machine:

showmount -e 10.1.11.64

I’m not sure if that works with windows server, but if it does, it should basically give you the answer.

@arnaudrigole Is the FOG directory located at the root of that server? Because you need the full path!

@Tom-Elliott Right you are.

@arnaudrigole " i think i don’t understand … but i recreated a shared directory by NFS services on my Win 2008R2, and when i try to mount it as : “mount -t nfs //SRVADM:FOG/Images /srv/cifs/SRVADM/images it return me :” mount.nfs : Failed to resolve server //SRVADM: name or service not known" , tried with IP -> same."

Your syntax is incorrect, it should be something like mount -t nfs SRVADM(or ip):/FOG/Images destinationpathhere (eg mount/images after doing mkdir mount/images)

// is only used for SAMBA/CIFS paths and won’t work for other methods of connecting.

Also, as a note, NFS needs full path to the destination when you try to mount it, not just to the shared folder. Not sure if that’s the case on your end!

Updated to version 6721 (latest) and now get http error 500 on the image management page. Running Ubuntu 15.10.

Relevant apache error:

[Tue Mar 15 13:18:16.188609 2016] [:error] [pid 3650] [client 192.168.1.31:54147] PHP Fatal error: Call to a member function get() on null in /var/www/fog/lib/pages/imagemanagementpage.class.php on line 70, referer: http://192.168.1.154/fog/management/index.php?node=about&sub=logviewer

Checked permissions and such but all seems fine, was working on earlier builds.

Imagemanagementpage.class.php was one of the updated files so I’m guessing there’s a typo somewhere.

After looking at the file, disabling FOG FTP Image size fixes this issue, so I’m guessing there’s an issue with that currently.

Centos7 storage node test

[root@fogstoragenode ~]# useradd test
[root@fogstoragenode ~]# nano password
[root@fogstoragenode ~]# passwd test <password
Changing password for user test.
New password: BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password: passwd: all authentication tokens updated successfully.
[root@fogstoragenode ~]# cat password | passwd test
Changing password for user test.
New password: BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word
Retype new password: passwd: all authentication tokens updated successfully.

I tried it again after that in case it would have trouble overwriting the old password, but that gave the same output.

Might be safer to have the opposite check (check for unlicensed and only then try to activate rather than check for licensed and try to activate when that doesn’t match) to prevent keys from burning. I think people would prefer their computers not activating because of language issues rather than keys burning.

@ch3i Server yes, clients not.

@arnaudrigole That and also because Windows doesn’t support NFS by default.