Best posts made by JJ Fullmer

@Tom-Elliott Not quite working.
Got past the partition count but got a different error

@Toby777 I think it might still work on larger drives and you can manually expand the partition. That’s pretty good for RAW from what I’ve seen. Trouble with RAW is that it does every sector of the drive no matter how much space is taken up. Before multiple and extended linux partitions became supported I only used it for very specialized images for computers that were always the same size hard drive.

@anthonyglamis said:

Arrowhead,

I am wondering if this is a DNS issue? My host are all “unable to resolve”.

So the unable to resolve thing doesn’t necessarily affect the active directory issue, but it is something of a dns issue. For example, If your dns or perhaps dhcp server assigns hostnames to the computers based on ip address unless you reserve it in the server (It’s an issue I had at my last job where the university had a custom dhcp server that set the hostname based on the ip address unless you manually reserved by mac address, it was annoying). My point is they could relate, but I’ve seen the active directory join work even when the host isn’t showing as green/up in fog. So I would make sure everything else is right first before seeing if this is the cause. For example, does wake on lan work, because that only works if the host is down, because well it has to wake it from being off. Point is the ad join functionality doesn’t depend on the gui host up/down function in my experience.

Are you also setting the hosts to join the active directory in the gui, or are you doing it in the pxe imaging menu at the computer. Your configuration looks correct for the joining default settings. So as long as that user can join a computer to the domain and the hostname doesn’t already exist on the domain it should work. Just want to make sure you’re clicking the checkbox to tell the host to join the domain.

Also, is the latest fog client/service installed on the computer’s in question?
Also once that box is checked it typically just joins the domain right then restart and all. And if someone takes it off the domain it will just join right back again.

Hope that helps in some way

@Wayne-Workman I see that now, You posted while I was writing my post so I didn’t see that. I got distracted whilst writing it.

@Arrowhead-IT I tried resizing the partition manually in windows to the smallest that windows would allow to shrink to see if it by chance would get past the resize test before resizing, but it didn’t work either. It was a long shot.

In the storage management of the fog gui is everything set correctly? IP address, interface, user/password and all that?
on the server what does your /etc/exports look like?

cat /etc/exports

What does fog say about your hard drive in the gui?
https://{fogip}/fog/management/index.php?node=hwinfo&id=1

I’ve seen mine mess up before and one of those configurations was just messed up. Maybe your ip isn’t static and it changed on you?
Other times a quick restart of apache refreshed and fixed the issue

sudo service apache2 restart

or

sudo /etc/init.d/apache2 restart

Or just a good old fashioned restart of the whole server can fix it to if it’s an odd bug in your server.
Though it’s most likely a simple configuration issue in the ui based on when this has happened to me a few times and since your nfs server is probably working since you were able to upload an image.
How big does the gui say your image is? You will need to enable “FOG_FTP_IMAGE_SIZE” under “General Settings” in the FOG Configuration then go to image management and list all images.

Hopefully one of those ideas helps.

@anthonyglamis So what is the current status? Did the new image upload and download successfully? Is AD working like magic with the new version?

@Wayne-Workman I just noticed that I missed this post, it was when I was on vacation. This hasn’t actually been a problem on this new network as much. If it happens to me again I’ll come back here or make a new post with the fog.log on anything having trouble.

@Tom-Elliott Great Success! It’s all good again.

@mrdally204 I usually set the owner and group of images to fog

sudo chown -R fog.fog /images

And I set the permissions to 775

sudo chmod -R 775 /images

Whether or not that’s the best security practice is arguable, and since your permissions are already 777 the owner being root probably doesn’t matter. But changing the owner might be worth a shot.

@anthonyglamis said:

I created those images in the previous fog version so is this a bug or am I not capturing the image correctly?
Also I deleted those images (Dell3450, LenovoE430) however they are still on my linux box, can I get those back into the fog server?

If they are still in the /images folder then yes. If they are in a different machine, still yes, just transfer the files to the new fog server /images folder.

Just make new images in the fog gui with the same settings and point them to the file names and they should work. Does that make sense?

@jc35 Just to be sure I understand what you’re trying to do,
You have an inventory system in glpi.
You want to make it so if you hit delete on a computer in your inventory rabbit mq sends a message to fog to wipe the machine and put a default image (like a retail windows or basic linux that the computer can be sold with I’m guessing) on the deleted computer.

So you want to click one button to delete the computer from your inventory and it automatically prepares itself to be safely disposed/surplussed/sold or what have you.

Do I understand correctly?

@Wayne-Workman
[Mon Jan 25 12:30:49.536526 2016] [:error] [pid 24884] [client 192.168.100.108:61538] PHP Fatal error: Uncaught exception ‘Exception’ with message 'FOGFTP: Failed to connect. Host: 192.168.100.100, Error: Undefined variable: whereA$

I couldn’t copy the whole error message from the terminal with ease, it appears to be ftp related. So I tried to ftp in only for it to not work on port 22 and on port 21 I get this message
OOPS: vsftpd: refusing to run with writable root inside chroot()

So this is a me accidentally running chmod -R 775 / instead of chmod -R 775 ./ and not cancelling it fast enough problem, not a fog problem at all.

@Wayne-Workman That makes me feel special Thanks

@MRCUR The IE stuff in appdata is where the shortcut files that are pinned to taskbar go, but to get it to work fully you need the ntuser.dat files. The script I posted copies that file from your customized profile into the default profile but only that file. Give my batch script a try. If you’re using sysprep, some customizations might disappear so you could run the script before sysprep then put the resulting C:\Users\Default in a network share somewhere then copy it back over after sysprep or after imaging.

Does that help at all?

@jc35 So I think you can do this
I would follow the help @Wayne-Workman gave you on this post
https://forums.fogproject.org/topic/6454/wipe-and-restore

Using the information of what the database tables need to say you could write a bash or python script to edit the mysql database of fog.
The next question is whether or not you need help with that part too.
The basics steps you would need to do

• make a remote mysql user with access to the fog database on the fog server.
• Compose and test some mysql commands remotely based on the tables you need to edit and make sure it works
• Take those commands and put them into a script. In bash it is possible to send a single command to mysql, I don’t remember the parameter of the top of my head though, I would have to go find a script where I did that if need be.

Hopefully that helps you get started.

I had set my snapins to a different directory (/images/snapins with /images being a symlink to /home/fogRootSystem/images)
But the original install had created the /opt/fog/snapins directory and put the ca ssl folders there.
But then it did it put the CA ssl folders with new keys in the new /images/snapins folder.

All day today I have been troubleshooting the client wondering why it suddenly stopped authenticating. Uninstalling and reinstalling, re-imaging, modifying the msi, resetting encryption data, running the fog install script with the --recreate-CA and --recreate-keys options. And nothing worked. Then I noticed the duplicate CA and SSL directories and got to thinking that maybe that’s not supposed to be a thing. So I moved the /opt/fog/snapins folder to my /images/snapins directory
mv -f /opt/fog/snapins /images/snapins then deleted the opt folder rm -fr /opt/fog/snapins then made a symlink ln -s /images/snapins /opt/fog/snapins Then I reran the fog installer like this ./installfog.sh --recreate-CA --recreate-keys -Y and now the client is working again (after reinstall on the client).

So a fix exists, but it seems that changing the snapins directory doesn’t work for the client and causes weird ca/ssl authentication errors.

It’s possible that something else I did fixed my issue, but I am 99.9% sure that the symlink and reinstall recreating the CA is what solved it.

@Tom-Elliott is on top of this problem
Check out this forum post https://forums.fogproject.org/topic/6315/hp-z640-nvme-pci-e-drive/37
I’m posting my results of testing on the /dev/nvme0n1 type drives with his current inits found here

32 bit Init: https://mastacontrola.com/init_32.xz
64 bit Init: https://mastacontrola.com/init.xz

To use them do the following

cd /var/www/fog/service/ipxe
sudo mv init.xz init.bck
sudo mv init_32.xz init_32.bck
wget https://mastacontrola.com/init.xz --no-check-certificate && wget https://mastacontrola.com/init_32.xz --no-check-certificate
sudo chmod -R 775 ./

Granted by the time dell gets you a replacement it might already be tested enough and the fix will just be in the latest trunk. But that’s what to do in case anyone else is looking.

@MRCUR I see what you’re saying. It would be less work to not have to manually pin some icons to the taskbar and then run the script.
Granted I have my default base image with my default profile on a esxi vm, so for me it is pretty easy to do. I suppose it could be possible to edit the ntuser.dat file manually to add in shortcuts. I’ll look into that, because it would certainly be easier.

@Wayne-Workman well, it happens on physical machines too. Maybe CentOS is just better than ubuntu for hosting fog?