@msi said in Snapin not running:

I checked the port 445. its open.

Then it’s likely just a DNS configuration issue: if the FOG server can’t resolve hostnames, then it can’t ping them. If you’d like help with that please open a new thread, though this is ultimately not a FOG issue, so it may be best to search other resources on how to configure DNS (assuming this is the issue).

ty solved

@x23piracy this is correct.

Based on the complexity requirements alone, this isn’t something easily done. Though depending on the version of FOG you’re using, you could create a crontab that could lookup all your hosts, see which are set to join the domain, and add any snapins you want automatically. You can even use the same principle during a deploy task through the use of postdownload scripts. Check if ad is to be used, if so, set the snapin for that host, and schedule that snapin task, then complete.

Of course i’m talking complex stuff to think about. But ultimately it’s not impossible, but it’s not automated in fog. Complexity level, i think, would be around a 6 or 7 on a 10 base scale meaning it’s not simple by any means, but it’s also not too hard. There’s some information on the use of the api system (assuming you’re using a version of fog with the api stuff) floating around the forums.

@wayne-workman said in Surface pro 4 gets stuck on init.xz (still):

@fry_p What caused it to be unable to image a Surface Pro 4? Has it ever worked at your location? When did it last work? What’s changed since then?

Hey guys. I realize more info is needed. However we don’t have another surface to test with. I can tell you it has been a while since we have done a pro 4. We did do a pro 3 with the same conditions without issue last week. It has worked at our location before albeit very sporadically with no rhyme or reason it seems. I’d say it has been months since the last pro 4, so I have updated FOG since then. I’m sorry I don’t have more info. If we get another pro 4 any time soon and if I am back to work, we will test. I suppose we can file this away for now. Right now, we only get 4’s for warranty replacements as the new Surface Pro is out so they are few and far between.

@george1421 I am on dnsmasq 2.76 and my ltsp.conf file is identical to what you posted.
All of my Dell’s are working 100% now. I am not sure why they did not initially, but they seem to be fine now. I will capture the pcap today with the Posiflex. Thanks!

@wayne-workman the fog client never handled this tasking.

The main tasking should work but we need to know what version of fog you’re using. Even then a new os may mean some manual intervention is required.

I’m back with some more info.
It looks like the problem was that udp-sender wasn’t started by the multicast manager service. If I restart the service, the udp-sender starts. I reboot the workstations and this time it starts deploying.

Thanks @george1421 Problem solved!

@voison If you have some time this weekend, I am willing to help you out via a screen share - PM me.

@Joe-Gill glad you found a quick fix. I’ll keep this ticket open though, as it points to a deeper issue in the client: PrinterManager has a thread safety issue.

@irfan4701 @george1421 XFS support has been added years ago. FOG 1.4.4 should be able to properly capture and deploy XFS partitions. Though it cannot shrink it! So you only need to change from XFS to EXT4 if you want resizable images…

See jdd49’s comment here:

XFS
Does not have the ability to shrink period. It can only grow. The only possible solution is to do a file backup using something like xfsdump, then recreate the filesystem. Or make the smallest partition possible when you first install, then grow after imaging.

so… as an update…
I stopped/disabled the fog replication service and used the same command as fog used to replicate the folder over from the fog images store to the synology images store.

After this, imaging from the storage node works as desired.

I’d really like to know how fog winds up pulling the Synology home page during the file compare… is it using http? what path is it trying to hit? I can set up a packet trace and try to find out, but I’m hoping someone can just chime in with the info.

@wayne-workman Running that command fixed the issue.

Hi,

in normal you don’t need any autologons, i just use it because i am working with windows 10 pro oem where you cannot have setupcomplete.cmd executed automatically, therefore i used the autologon stuff with first logon commands in my unattend.xml.

If you don’t need to do anything special remove autologons in your unattend.xml

Regards X23

@sebastian-roth

I ended up switching from the dev-branch to the working branch and re-ran the installer. Everything worked fine.

@coxm Two questions:

What version of fog is this? Is your master node on the same version as the storage nodes?

@coxm Now that you have a working solution, I’ll tell you a bit easier way to go about this.

If you know ahead of time you will keep the OS on a thin image and have the /images on a separate disk then before you install fog create the /images directory and mount your image storage disk over /images and finally install FOG. There will be nothing to change post installation. If you see you need to add the disk after fog is install there are a few more steps involved but that’s basically it.

https://forums.fogproject.org/topic/11048/moving-fog-s-images-files-off-the-root-partition-2017-edition

If you don’t want to disable selinux (or set to permissive) I’ve had luck under CentOS 7 using the following command:

$ sudo setsebool -P tftp_home_dir 1

I thought I might expound a little. To test my Fog TFTP server, I used the TFTP client in Windows. If you would like to do the same, you need to permit TFTP through your Windows firewall.

When I first tried to pull the undionly.kpxe file using the Windows client, I was given the following error:

PS C:\Users\jarcher> tftp -i 172.19.1.30 GET undionly.kpxe Connect request failed

Looking into my /var/log/audit/audit.log file I saw the following:

$ sudo grep tftp /var/log/audit/audit.log ...lots of other stuff here... type=AVC msg=audit(1519225691.090:214): avc: denied { read } for pid=3164 comm="in.tftpd" name="undionly.kpxe" dev="dm-0" ino=34386610 scontext=system_u:system_r:tftpd_t:s0-s0:c0.c1023 tcontext=unconfined_u:object_r:default_t:s0 tclass=file ...also lots more here...

if you use audit2allow you can get some hints on how to fix this error:

$ sudo grep tftp /var/log/audit/audit.log | audit2allow -m tftpd module tftpd 1.0; require { type default_t; type tftpd_t; class file { getattr lock open read }; } #============= tftpd_t ============== #!!!! WARNING: 'default_t' is a base type. #!!!! This avc can be allowed using the boolean 'tftp_home_dir' allow tftpd_t default_t:file { getattr lock open read };

Note, you might have to install the policycoreutils-python package to get audit2allow

Now just run the original command I mentioned above to allow access to the files:

$ sudo setsebool -P tftp_home_dir 1

SELinux is still set to enforcing:

$ sestatus SELinux status: enabled SELinuxfs mount: /sys/fs/selinux SELinux root directory: /etc/selinux Loaded policy name: targeted Current mode: enforcing Mode from config file: enforcing Policy MLS status: enabled Policy deny_unknown status: allowed Max kernel policy version: 28

And now the TFTP transfer works in Windows:

PS C:\Users\jarcher> tftp -i 172.19.1.30 GET undionly.kpxe Transfer successful: 95338 bytes in 1 second(s), 95338 bytes/s

@tom-elliott
Thank you for your reply. I thought about this too but I’m a bit uncomfortable with modifying the FOG code. Plus, it would break if I upgrade.
I got another idea yesterday, after writing this post. I was thinking about a script, that would run from cron, about every 10 minutes. It would check if udp-sender is running. If it isn’t, it would just exit. If it is, it would start monitoring the process and, when it finishes, it would launch my custom code.
This would work if udp-sender runs only during multicast. I suppose this is the case. I don’t see any reason for it to run otherwise.
How does this sound?