@george1421

By and large I agree with you about the hash algorithm being irrelevant, however, some entities have requirements for minimum acceptable hashing for such kind of verification. I think a baseline of a choice between md5 and shasum baseline is fine, especially while development of the feature is ongoing (md5 is still widely used in forensics), however that will not always be the case and building support in for additional options might be better. The time cost involved is something the end user should accept when they select the additional complexity.

Just as a test, I timed sha 512 on my Windows 10 image. Here is the results:

d0715180-198f-4f02-93d6-a638d573b1e9-image.png

Took about 2m 8s for 8 GB give or take. So the wait isn’t terrible at higher algorithm complexity. This test was done with a two virtual processor VM on a server with a bunch of other vms running.

Interestingly enough, the shasum utility on ubuntu can compare hashes to a text file for verification.

4e873e2c-fd44-4f6e-b026-0462cccbd356-image.png

Also, I don’t think the hash need be taken inline with the imaging process, but be done post imaging, either on demand, or run in background automatically before image is made available for distribution.

Thoughts?

@Quazz While I do understand the good intend in this I think it’s very hard to maintain. We see enough issues with trying to make it work in the different distros. Adding the Stream PHP versions will be a nightmare I reckon.

@vdbmartial Persistent groups plugin is your answer. This is where you create a host template and then apply that template to the host during registration. Then when you deploy an snapin, printer, or setting applied to the template host, that will get applied to the target computer before imaging.

There currently is a bug in the process that we are working through here: https://forums.fogproject.org/topic/15084/persistent-groups-snapins-added-to-host-but-not-deployed

@sebastian-roth Ok thanks

@george1421 Thanks for the input!

I’m not looking to specifically put F2B in; I am putting in code to log to a file login failures and successes, then the SysAdmin can choose to setup a F2B jail based on that. I believe heavily in separation of responsibilities, so I will definitely look into writing a proper tutorial.

Do you think code for simply logging the login attempts would get merged?

@Greg-Plamondon said in REQUEST: UltraVNC connect to client pc via fog interface...:

No, I just get a white page. I think that’s trying to use Java.

I realize that this will sound harsh, but if this bit doesn’t work, what the FOG Wizards can do will not matter. Look at your settings you may need to enable the web interface. We use TightVNC in my organization and when I access that page I just got a white page with a link to the tightvnc website. We use the vnc viewer so I don’t know if the web ui was ever configured.

@coolp Which Linux OS and version do you use? As George said we pretty much use what the OS comes with. Though maybe not in all cases. Let us know what you use and we can take a look.

@Sebastian-Roth said in Feature request for FOG 1.6.x - Support GRUB as UEFI exit mode:

So back to my point: Why would you chainload to another iPXE binary again for exiting?

I don’t have a specific use case at the moment. So adding additional features without a specific reason may not be as valuable as I initially throught.

Also I had a setback with grub. For some reason grub isn’t loading the config file that is uploaded, but using tftp to connect back to {next-server} (guess) and picking up the grub config file I had there. It is picking up the config file from there, I’m just not sure how it knows where to get the file from. Possibly from dhcp request. I’m still working with it, but grub isn’t quite as dynamic as I would have hoped to find uefi boot partitions.

Ran this from the Ubuntu 18 box:

root@ubuntu18:~# zstdmt -dc </images/_Windows10Prox641909/d1p4.img | partclone.info -s - Partclone v0.3.11 http://partclone.org Showing info of image (-) File system: NTFS Device size: 9.9 GB = 2412369 Blocks Space in use: 9.6 GB = 2351625 Blocks Free Space: 248.8 MB = 60744 Blocks Block size: 4096 Byte image format: 0002 created on a: 64 bits platform with partclone: v0.3.13 bitmap mode: BIT checksum algo: NONE checksum size: n/a blocks/checksum: n/a reseed checksum: n/a

It seems possible to do as a plugin. I’m not suggesting that it be approved or denied only that its possible. It will require the fog admin to acquire an API key from Dell.
As for the additional fields someone would have to write a custom plugin to extend FOG.

ref: https://gist.github.com/teroka/0720274b87b77fe7171f
ref: https://www.apajove.com/knowledge-base/dell-v5-warranty-api/
re: https://van-gelderen.eu/getting-dell-warranty-info-in-powershell/

https://github.com/FOGProject/fogproject/pull/409/files
https://github.com/FOGProject/fogproject/pull/410/files

Testing systems Dell o7010 both fog server and client computer. Both systems have local ssd sata drives. The target computer is running a customized linux kernel 5.6.18 and a customized init but both as based on FOG 1.5.9. The customization was done to aid in debugging and bench-marking the systems.

Testing script

mkdir /mnt/locdsk mount /dev/sda1 /mnt/locdsk mkdir /images mount -o nolock,proto=tcp,rsize=32768,wsize=32768,intr,noatime "192.168.10.1:/images/dev" /images #Test 1 creation of local and remote file by target computer time dd if=/dev/zero of=/mnt/locdsk/L10gb.img count=1024 bs=10485760 time dd if=/dev/zero of=/images/R10gb.img count=1024 bs=10485760 #Test 2 cp files to and from server time cp /mnt/locdsk/L10gb.img /images time cp /mnt/locdsk/L10gb.img /images/L10gb-1.img time cp /images/R10gb.img /mnt/locdsk time cp /images/R10gb.img /mnt/locdsk/R10gb-1.img #Test 3 scp files to and from server time scp /mnt/locdsk/L10gb.img root@192.168.10.1:/images/L10gb-2.img time scp /mnt/locdsk/L10gb.img root@192.168.10.1:/images/L10gb-3.img time scp root@192.168.10.1:/images/dev/R10gb.img /mnt/locdsk/R10gb-2.img time scp root@192.168.10.1:/images/dev/R10gb.img /mnt/locdsk/R10gb-3.img #Test 4 ssh pipeline to and from server time cat /mnt/locdsk/L10gb.img | ssh root@192.168.10.1 "cat > /images/L10gb-4.img" time cat /mnt/locdsk/L10gb.img | ssh root@192.168.10.1 "cat > /images/L10gb-5.img" time ssh root@192.168.10.1 "cat /images/dev/R10gb.img" | cat > /mnt/locdsk/L10gb-6.img time ssh root@192.168.10.1 "cat /images/dev/R10gb.img" | cat > /mnt/locdsk/L10gb-7.img

Testing results as captured.

## Building the test files both local and remote # time dd if=/dev/zero of=/mnt/locdsk/L10gb.img count=1024 bs=10485760 10737418240 bytes (11 GB, 10 GiB) copied, 20.2216 s, 531 MB/s **real 0m20.223s user 0m0.001s sys 0m6.460s # time dd if=/dev/zero of=/images/R10gb.img count=1024 bs=10485760 10737418240 bytes (11 GB, 10 GiB) copied, 93.3867 s, 115 MB/s **real 1m33.390s user 0m0.003s sys 0m5.369s ## Confirm that files exist and are properly sized # ls -la /mnt/locdsk/ total 10485785 drwxr-xr-x 3 root root 4096 Oct 9 08:25 . drwxr-xr-x 3 root root 1024 Oct 9 08:23 .. -rw-r--r-- 1 root root 10737418240 Oct 9 08:26 L10gb.img drwx------ 2 root root 16384 Jan 10 2013 lost+found # ls -la /images/ total 10519109 drwxrwxrwx 3 sshd root 63 Oct 9 2020 . drwxr-xr-x 19 root root 1024 Oct 9 08:23 .. -rwxrwxrwx 1 sshd root 0 Sep 28 13:36 .mntcheck -rw-r--r-- 1 root root 10737418240 Oct 9 2020 R10gb.img drwxrwxrwx 2 sshd root 26 Sep 28 13:36 postinitscripts ### Copy Local to Remote ### # time cp /mnt/locdsk/L10gb.img /images ** real 1m34.821s user 0m0.083s sys 0m7.314s # time cp /mnt/locdsk/L10gb.img /images/L10gb-1.img **real 1m34.759s user 0m0.046s sys 0m6.801s

cp_local_remote_client.png
cp_local_remote_server.png

### Copy Remote to Local ### # time cp /images/R10gb.img /mnt/locdsk **real 1m41.710s user 0m0.084s sys 0m11.327s # time cp /images/R10gb.img /mnt/locdsk/R10gb-1.img **real 1m41.520s user 0m0.095s sys 0m11.392s

cp_remote_local_client.png
cp_remote_local_server.png

### SCP Local to Remote ### # time scp /mnt/locdsk/L10gb.img root@192.168.10.1:/images/L10gb-2.img The authenticity of host '192.168.10.1 (192.168.10.1)' can't be established. ECDSA key fingerprint is SHA256:OpIsFYWVDCr/ovMlmPPSl46jpT332P3+BHnchdxzTCI. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.10.1' (ECDSA) to the list of known hosts. root@192.168.10.1's password: L10gb.img 100% 10GB 110.0MB/s 01:33 **real 1m40.007s user 0m44.460s sys 0m13.378s # time scp /mnt/locdsk/L10gb.img root@192.168.10.1:/images/L10gb-3.img root@192.168.10.1's password: L10gb.img 100% 10GB 109.5MB/s 01:33 **real 1m37.404s user 0m44.420s sys 0m13.068s

scp_local_remote_client.png
scp_local_remote_server.png

### SCP Remote to Local ### # time scp root@192.168.10.1:/images/dev/R10gb.img /mnt/locdsk/R10gb-2.img root@192.168.10.1's password: R10gb.img 100% 10GB 101.9MB/s 01:40 **real 1m44.166s user 0m43.986s sys 0m22.887s # time scp root@192.168.10.1:/images/dev/R10gb.img /mnt/locdsk/R10gb-3.img root@192.168.10.1's password: R10gb.img 100% 10GB 102.0MB/s 01:40 **real 1m44.620s user 0m43.437s sys 0m23.061s

scp_remote_local_client.png
scp_remote_local_server.png

### SSH Pipeline Local to Remote ### # time cat /mnt/locdsk/L10gb.img | ssh root@192.168.10.1 "cat > /images/L10gb-4.img" root@192.168.10.1's password: **real 1m35.562s user 0m42.701s sys 0m12.975s # time cat /mnt/locdsk/L10gb.img | ssh root@192.168.10.1 "cat > /images/L10gb-5.img" root@192.168.10.1's password: **real 1m35.749s user 0m43.478s sys 0m11.166s

ssh_local_remote_client.png
ssh_local_remote_server.png

### SSH Pipeline Remote to Local ### # time ssh root@192.168.10.1 "cat /images/dev/R10gb.img" | cat > /mnt/locdsk/L10gb-6.img root@192.168.10.1's password: **real 1m43.745s user 0m44.738s sys 0m20.828s # time ssh root@192.168.10.1 "cat /images/dev/R10gb.img" | cat > /mnt/locdsk/L10gb-7.img root@192.168.10.1's password: **real 1m43.564s user 0m43.976s sys 0m21.966s

ssh_remote_local_client.png
ssh_remote_local_server.png

@Wayne-Workman said in Feature request for FOG 1.6.x - Scheduled database maintenance:

I should add I’m not talking about history. I’m referring to the issues that literally break fog. This stuff:

Definitely good you phrase this more explicitely!! We should discuss those two things separately (maybe not in different topics though).

While we tell people to sometimes try a cleanup of the DB I am not sure how much issues in the code are still causing this or if this is related to people coming older versions and have not done a cleanup in a long time. Don’t get me wrong, I am not saying the code is perfectly fine, I just don’t know as we don’t have enough evidence that this happens all the time. We would expect way more people to ask about this in the forums.

On the other hand I do agree that running those cleanup (not the history ones!) once a week or even daily wouldn’t hurt:

DELETE FROM `hosts` WHERE `hostID` = '0'; DELETE FROM `hostMAC` WHERE hmID = '0' OR `hmHostID` = '0'; DELETE FROM `groupMembers` WHERE `gmID` = '0' OR `gmHostID` = '0' OR `gmGroupID` = '0'; DELETE FROM `snapinGroupAssoc` WHERE `sgaID` = '0' OR `sgaSnapinID` = '0' OR `sgaStorageGroupID` = '0'; DELETE FROM `snapinAssoc` WHERE `saID` = '0' OR `saHostID` = '0' OR `saSnapinID` = '0'; DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC` WHERE `hmPrimary` = '1'); DELETE FROM `hosts` WHERE `hostID` NOT IN (SELECT `hmHostID` FROM `hostMAC`); DELETE FROM `hostMAC` WHERE `hmhostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `snapinAssoc` WHERE `saHostID` NOT IN (SELECT `hostID` FROM `hosts`); DELETE FROM `groupMembers` WHERE `gmHostID` NOT IN (SELECT `hostID` FROM `hosts`);

You don’t want to run those on a regular basis I find because it can kill running tasks/sessions if those were setup to run over the weekend for example (state ID see here)

DELETE FROM `tasks` WHERE `taskStateID` IN ("1","2","3"); DELETE FROM `snapinTasks` WHERE `stState` in ("1","2","3"); TRUNCATE TABLE multicastSessions; TRUNCATE TABLE multicastSessionsAssoc; DELETE FROM tasks WHERE taskTypeId=8;

And history is another story altogether…

TRUNCATE TABLE history; TRUNCATE TABLE userTracking;

@Tom-Elliott Good thoughts about not focusing on bash scripts. My thoughts on this…

At work, if you can point your peers to documentation saying “this project only supports this distribution” Generally your peers accept it.

It’s been a topic that has come up before: Dropping installer support down to one or two distributions. CentOS and/or Debian. This probably deserves another forums topic.

At this point, I think supporting one distribution is best. I don’t care which one it is, though Debian probably has the best shot at longevity. I fear CentOS will slowly become irrelevant to many as Red Hat focuses on supporting IBM (their parent company), giving less focus to everything else.

@Tom-Elliott said in Feature request for FOG 1.6.x - FOG Installer instll DNSMASQ:

I’m on board for this as well, though wouldn’t mind some help in implementing.

Sure, I will! There is no rush yet. I am working on making the move from 1.5.x to 1.6.x first and then we’ll look into all the feature requests opened lately.