@george1421 He’s referring to the autologout module, but you’re definitely not wrong.

@blkeller, duly noted. Updating the time restraints means updating the entry in SQL, not hard, and I can have that done fairly easily. Even not allowing the setting to hold on to anything less than 5 minutes isn’t too hard, though do I set it to 0 if it’s below 5? Just thoughts on how best to approach. I don’t think it should warrant an “error” to update the host because that field isn’t really necessary for normal imaging functions.

@wayne-workman Absolutely. As soon as I can I will.

@Julianh I am sorry to say that but your setup is quiet complex with so many disks mounted in various locations and I don’t think we’ll be able to reliably guide you through a migration here in the forums. I am not sure what to advice. As Wayne said, 1.4.4 can deploy 1.2 images. So unmounting and moving the disks to the new system should work.

@x23piracy Missing since RC10 - see here: https://github.com/FOGProject/fogproject/tree/1.5.0-RC-10/packages/tftp

@Tom-Elliott We should definitely put up a big note for the final 1.5 release.

@shad0wguy It would be helpful once you prove this setup as reliable, if you could write a tutorial explaining how you setup FOG on this device as well as what others need to watch out for. I don’t think the FOG Project developers will support this configuration directly, but I’m sure there are others in certain situations with your exact use case. Your configuration may help guide them.

Please consider contributing to the cause, if you can.

@tesparza well that would certainty do it. Reset Encryption Data is generally not advised to be done unless you specially do something to the client that would require it.

Hey Guys, thanks for leading me in the correct direction… one of our NEs worked with me today, what we found was… well… lets just say that I am glad I am a server engineer and not a network engineer.

We config’ed one port for Spanning tree fast port and it connects correctly. Now I have to go back to my Sys Eng and ask him WTF?!?!

Thanks again,

Rbryant

@dylanderr Please read through this:
https://wiki.fogproject.org/wiki/index.php?title=Password_Central#For_Storage_Nodes

The settings you set in the web UI only tells the fog services what credentials to use, it does not set the actual password in mysql. I will clarify this in the article, thanks for pointing it out.

@boyan-biandov We have an article now that details how to migrate FOG safely: https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG

I’m going to assume that once a volume has been encrypted, it remains that way even if bitlocker gets turned off, but it simply lends anyone access to it. (and is therefore generally not an issue for users).

If you could please use the commands Sebastian posted so we can see what partitions we’re dealing with, we might be able to figure this out.

@wayne-workman said in Image not syncing between nodes:

If you run this command from your Master Node, it will prompt you for the storage node’s local fog user’s password. You can find that in that node’s storage management area or from this file on it: /opt/fog/.fogsettings

rsync <options> <source> <destination>

rsync -r --bwlimit=6250 fog@10.134.200.230:/images/Laptop2.1 /images rsync -r --bwlimit=6250 fog@10.134.200.230:/images/Laptop /images

The 6250 is supposed to be 6250Kbps, or 50Mbps. If you want slower, you can do the math to figure out what you need with the calculator I reference below.

It took some times but it is working after issuing the rsync command. I had to delete the image from the NJED node after rsync completion.

@tom-elliott

[root@ianos ~]# ls -lhat /var/www total 4.0K drwxr-xr-x 4 root root 47 Feb 4 21:54 html drwxr-xr-x 4 root root 41 Feb 3 23:26 . lrwxrwxrwx 1 root root 18 Feb 3 23:26 fog -> /var/www/html/fog/ drwxr-xr-x 2 root root 6 Oct 19 23:39 cgi-bin drwxr-xr-x. 22 root root 4.0K Aug 21 21:29 .. [root@ianos ~]# ls -lhat /var/www/html total 12K drwxr-xr-x 13 apache apache 4.0K Feb 4 22:31 fog drwxr-xr-x 4 root root 47 Feb 4 21:54 . drwxr-xr-x 4 root root 41 Feb 3 23:26 .. -rw-r--r-- 1 root root 45 Jan 29 2015 index.php

Although the above don’t seem erroneous to me, I followed your advice and deleted
/var/www/fog and /var/www/html/fog. After re-running the installer multicasting works as it should. Apparently it was a right guess 😉
Thanks a lot for your nice work!

@gmonk I use Fog 1.3.3 for all my windows 10 captures and deploys works great in VM.

@sebastian-roth Here is a new thread: https://forums.fogproject.org/topic/11393/chromium-image-issues-after-updating-server

I got past the NFS-problem by changing the mount string! Thank you. 🙂

Okay that was it. Thanks. I reset my image using ext4

@tom-elliott said in Quick host registration is registering my computers with the Mac address as the hostname:

I’ve not added any special strings as it actually adds quite a bit of complexity to the overall workflow.

While it’s not “overly” hard to add such a feature, I think this is something more in line with a user being able to edit and figure out.

First, you have to understand, you have to detect your “special” strings and replace them with the corresponding value. During Quick Registration, we haven’t quite gotten the inventory of the host yet, until after the host has been registered. It shouldn’t be too hard to add, but again it’s not a simple thing either.

And where do we “stop”. For example, what strings should we allow, vs, not allow?

The file you can edit, if you’d like to try adding this feature again, is located (with 1.4.4 at least) /var/www/fog/lib/reg-task/registration.class.php There’s two methods, _quickRegAuto and _quickReg, you’d want to modify the _quickRegAuto specifically.

You’ll notice that inventory isn’t taken into account here, and therefor using the inventory data for the hostname would have to be done within the init’s.

In particular, the init file /bin/fog.auto.reg would need to be modified after the inventory line.

I’m bringing this to your attention only because FOG has changed quite a bit since 0.29/0.3x days and while this feature may have been there in the past, we have tried to make things much more manageable in general. This means some features from olden times may have been removed due to the complexity involved.

Hopefully you understand.

@tom-elliott I understood most of the things that you said, but I am not sure what strings of the code should I have to change. Can you help me with that?

@tesparza did you run PrinterManagerHelper on a computer that has the printer already installed? It will give you all the field values, as sometimes even things such as Model aren’t what you think they should be. Did you also try using the generic printer inf the tool will point you to? It should work for the majority of printers.

@Wayne-Workman until we know more information its doubtful the powershell script will likely do anything to resolve his issue, as we do not yet fully know what it is. Based on the errors this seems to be a simple configuration issue for now.

As a note, the client log states that it has already attempted to configure the printer, not that it is installed. If a printer configuration fails to add once, there is no reason for the client to continue spamming your printer spooler every cycle unless the config has changed. If you scroll up more in the log to where the client first attempts to add the printer, you’d probably see an error message similar to what PrinterManagerHelper is giving you.

So, the mysql-fix postet by Tom Elliot helped. No need to rerun the fog installer.

@tom-elliott said in Ubuntu is FOG’s enemy:

TLDR; … or run the ALTER USER syntax shown below.

As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

The “fix” if you must do it manually is to open a terminal and obtain root:
Super (Windows Key) + T then sudo -i (in most cases).

From there, open mysql with mysql -u root

NOTE: MySQL MUST be run with ROOT.

Run:

ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY ''; AND
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

It’s okay if one of them fails. This is going to fix Most people’s issues.

I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

To prevent this problem from happening in the future you could run:

apt-get -y remove unattended-upgrades (AS Root again).

@fradlo ok well that rules out stp then.

I guess the next round of testing should be this

Lets get a pcap (packet capture) of the pxe booting process. Since the fog server and the target computer are still connected to the same switch I want you to follow this process (I know you are wireshark capable, but lets follow this route): https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue Lets add to the filter sting port 80 too, so we can capture http requests to the FOG server. Run the pcap all the way through registration. Upload the pcap to a google drive or drop box. You can either post the link here or DM me the link so I can take a look at it.

We need to rule out anything in your environment that could be causing this issue. It may be worth setting up isc-dhcp server on your fog server for a test. Keep that unmanaged switch between your FOG server and your target computer and unplug the unmanaged switch from your business switch. and then with isc-dhcp server running see if pxe booting behaves any differently. I have 790s in our office and they pxe boot just fine. So unless the bios is the original release on the 990s pxe booting should just work.