/etc/pam.d/vsftpd looks fine

#%PAM-1.0 session optional pam_keyinit.so force revoke auth required pam_listfile.so item=user sense=deny file=/etc/vsftpd/ftpusers onerr=succeed auth required pam_shells.so auth include password-auth account include password-auth session required pam_loginuid.so session include password-auth

ftpusers file:

# Users that are not allowed to login via ftp root bin daemon adm lp sync shutdown halt mail news uucp operator games nobody

Great. bzImage 6.1.89 fixed it. Will test newer ones to see where it breaks.

@cros I’m kind of spit balling here but your imgargs line especially around nfsroot doesn’t really follow what I expect.

FWIW here is what I have in my guide for debian 11. (I really don’t keep up with current distros anymore)

kernel tftp://${fog-ip}/os/debian/Server11.3/linux initrd tftp://${fog-ip}/os/debian/Server11.3/initrd.gz imgargs linux initrd=initrd.gz root=/dev/nfs boot=casper netboot=nfs nfsroot=${fog-ip}:/images/os/debian/Server11.3/ locale=en_US.UTF-8 keyboard-configuration/layoutcode=us quiet splash ip=dhcp rw boot || goto MENU

For me your imgargs line stands out as is your 192.168.7.5 server your fog server or a different server? If its your fog server you can make the line a bit more portable by using ${fog-ip} which will be replaced by the IP address of the fog server by iPXE. Secondly did you create an /nfs share on your fog server because that is not one of FOGs standard nfs shares. On the fog server you should be able to run the command showmount -e 127.0.0.1 to see the list of nfs shares on the fog server. In my imgarg command you can see I’m using /images/os which is in the path of /images on the fog server and /images is an NFS share.

ref: https://forums.fogproject.org/post/150256

Hello, some one can help me ? 😞

@Tom-Elliott woo not sure how i managed to miss that but its working as described. Thanks.

I believe I have a viable migration process to get FOG services moved from set of servers to another set. This process takes into account Locations, Storage Groups, existing Hosts, etc. The system I’m migrating has 7 remote sites so that’s 8 locations and 8 servers - one FOG server and 7 FOG Storage Nodes, each at the end of a Static VPN WAN. The initial FOG server is an alias ‘fogserver’ in DNS and DHCP is served out by MS Domain Controllers at each site. Each Storage node serves out all that is needed for each remote location (PXE, initrd, snapins, and images). Each storage node is the master of its own storage group. We do replication manually, so there may be some snapin and image replication issues in this process that I can’t account for.

The process requires being able to harvest the digital identity of the initial FOG server for use on the replacement FOG server, so the replacement server needs the same name and IP address. This is necessary to allow existing hosts to be easily ‘acquired’ by the new system since the Hosts. I pursued a side-by-side migration that worked fine PXE booting->host registration->imaging, but failed for existing Hosts and, for unknown reasons, even new Hosts failed all software distribution steps. The idea of placing FOG required scripts in group policies wasn’t appealing for my purposes since we need the FOGService to work without the machine joining a domain.

I’m currently testing and will have a process “doc” soon. I’m interested in posting this process for FOG Project’s use if the powers that be find it useful.

I’ll post it here when it’s completed.

It seems to me that the need to change Linux distros is an age-old requirement as various Linux OSs have been dropped or usurped. Migration of FOG from CEntOS to any other Debian Linux should be well documented.

More soon.

Jim Graczyk

@Tom-Elliott Thank you! This helps a lot! Funny enough, it was tftp-server that I installed. I suspect we may have had a different issue (maybe during a patch management cycle) and these things just got tied together.

@george1421 I appreciate your response. I went ahead and tried to install ubuntu 24 via a USB drive and got the same issue. I’m going to reach out to the manufacturer.

@JJ-Fullmer @Tom-Elliott

I’ve found a work around. I now have /images on USB HDD passed through the to VM. When I run a standard back up of the VM via the VM software (Virtualization Station), it only back-ups the OS VM drive.

For the /images drive - I use a sync program to back-up the files, not the disk .

@Tom-Elliott

Hi Tom,

We have added a column to the ‘location’ table in the fog database and we have given this column an ENUM ‘http’, ‘https’. The error message disappeared.
Should anyone run into the same problem, you can at least remove the error message from your logs.

We still have image-task problems but we’ll deal with those now.

Thanks.

Regards, sassonie

hello, i’m the original author of the Subnet Groups plugin: I wrote and committed the first version of its code back in 2019 (https://github.com/FOGProject/fogproject/pull/289).

i just wanted to inform you that in our environment (currently equipped with the last stable version of FOG) everything is working alright, we never had issues with the plugin even though we are used to update our systems on a regular basis.

as @Tom-Elliott mentioned, problems might arise due to incorrect IP addresses mapping: on our system, we had to set up a dynamic DNS server which has the job to automatically keep track of the actual host IPs based on their hostname; without this (or some alternative solution to correcly associate IPs with hosts) the plugin is not going to work properly.

best regards.

Side note, it appears that the KEA DHCP server in pfSense 2.7.2 does not properly support serving the correct boot file to BIOS vs EFI systems. It all works fine with Windows DHCP. This had nothing to do with my original issue.

The purpose of me using Capone for me is because we use all hps so I already have Capone configured to serve the golden image based off of the system-manufacturer matching HP

@george1421 said in Multicast stuck:

[09-18-24 9:36:35 am] Interface not ready, waiting for it to come up: 10.54.68.101
[09-18-24 9:36:45 am] Interface not ready, waiting for it to come up: 10.54.68.101
[09-18-24 9:36:55 am] Interface not ready, waiting for it to come up: 10.54.68.101

If you disable the storage node then you will get this message inside the log.

I found out that it wasn’t a FOG problem but i mixed up some vlans together.
Multicast works now. Problem solved.

@george1421 Thanks its working

Not sure why setting the LDAP plugin manually I couldn’t get it working … but I exported the plugin config from an old FOG instance and imported it in the new one and it worked, so I think you can mark this as solved 😉