Topics created by FallingWax

@fallingwax Yes, look in the history table in the database. It’s only available via SQL.

@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!

@fallingwax FWIW, I just checked at the H330 is $155 more than the S130. For a moment I thought they removed everything but the S130, but you need to select the hot plug drive trays before the H330 is an option. I know it was there because I purchased a R330 in July and linux is installed on that box right now, so know I didn’t pick a S130. But anyway, I hope you are able to turn on that option in the firmware. It looks like the S130 is using the intel software raid controllers, so you may have some luck with madm.

@sebastian-roth Updated to working this morning. I’ll post an update after we get a few machines imaging. Thanks again for your help.

@FallingWax Ok, now I see what’s wrong here. Thanks for reporting this issue. Moved your post to bug reports. When changing the way FOG exports the DB we obviously missed out on fixing the backup script as well. No one reported yet so we didn’t notice until now. You can edit that script and exchange line 74 which starts like wget ... with the following call: wget --no-check-certificate -O O $backupDir/mysql/fog.sql "http://$ipaddress/$webroot/maintenance/backup_db.php" --post-data="type=sql&fogajaxonly=1" 2>>$backupDir/logs/error.log 1>>$backupDir/logs/progress.log 2>&1 This is until we fixed this in the official code… @Tom-Elliott Mind having a look if this call is about right?

@Wayne-Workman Good point. Thanks for your help

@FallingWax Good to hear.

@Wayne-Workman Thanks! That cleared it up.

First check your disk usage on the remote node as Tom said. Check it with this command: df -h look for partitions with 99% or 100% usage. @FallingWax I remember having this problem although I can’t remember what I called the thread title… it’s here in the forums somewhere. But, basically I figured out that very large images were not completing replication within the grace window and the fog image replicator would just kill the old replication task and start it again. I brought this issue up to @Tom-Elliott at the time and he coded a fix - the fix made the image replicator aware of prior spawned lftp instances, and it would wait for those instances to complete before trying to restart them. Maybe something in the code base is goofed, I’m not sure. But you need to look at this setting and write down what it is: Web Interface -> FOG Configuration -> FOG Settings -> FOG Linux Service Sleep Times -> IMAGEREPSLEEPTIME So write that down, it’s in seconds. Next you need to go through your replication logs. Tom pointed out the places in the filesystem but they are also available via the web interface here: Web Interface -> FOG Configuration -> Log Viewer -> Image Replicator. You need to figure out if the image replication sleep time is close to when the image replicator just restarts the transfer - or not. If it’s close to when it restarts, this could mean that there’s an issue with the image replicator keeping track of lftp instances that it created. There could of course be other issues that we don’t know about so you should be extra observant when looking through all of this stuff.

@FallingWax Check the other post we’re playing tag between?

I need to revisit the image integrity plugin.

@Wayne-Workman Thanks! I ended up needing rename /opt/fog/.fogsettings and run the installer fresh but it was able to update successfully.

@FallingWax Cool, I’m glad you found a way. If you have any further questions that are not on this thread’s topic, please open a new thread and we would be glad to help you.

We have had people with dual-homed clients have issues prior and those were not resolved. I think kernel arguments for network address can be passed and inits then look for that network and any interfaces without it be shut down. I can mess with this maybe Friday or sunday.

@FallingWax yes. We have no generic accounts in fog. Everyone has their own account. This enables tracking in the history table however we have yet to need it. With a user account per person you also know who last imaged, who images were made by, who snapins were made by, and so on. Those items are in the web interface.

@Tom-Elliott I just shared the file with you.

Not many folks use that feature, since imaging is far faster than trying to repair an infected os. Keep watching this thread tho. Someone might speak up.

@george1421worked perfectly. thanks!