• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. george1421
    3. Topics
    • Profile
    • Following 1
    • Followers 64
    • Topics 113
    • Posts 15,289
    • Best 2,770
    • Controversial 0
    • Groups 2

    Topics created by george1421

    • george1421G

      How to configure pfSense for netbooting

      Tutorials
      • • • george1421
      1
      0
      Votes
      1
      Posts
      7.3k
      Views

      No one has replied

    • george1421G

      Configure FOG Database to use INNODB Engine

      Tutorials
      • • • george1421
      1
      0
      Votes
      1
      Posts
      346
      Views

      No one has replied

    • george1421G

      Performace testing slow FOG Imaging

      Tutorials
      • • • george1421
      5
      1
      Votes
      5
      Posts
      902
      Views

      george1421G

      Target disk subsystem

      In this section we are going to test the target computer’s performance to create a 1 GB file on local storage using the linux dd command. The dd command will create this 1GB file and time the creation process for us. Just be aware that this is a data distructive test. The contents of your local storage device will be erased during the test. Don’t perform this storage bandwidth test on a disk where you can not afford to lose the data.

      The hardest step in the process is finding the local storage device name, removing all partitions on the disk, and then creating a new partition for our testing.

      First lets find the name of your local storage disk. We will use the lsblk command to locate the linux device name. In the figure below you see the linux device name is sda for a sata attached disk, It has 2 partitions sda1 sda2

      # lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 238.5G 0 disk ├─sda1 8:1 0 512M 0 part /boot/efi └─sda2 8:2 0 238G 0 part / sr0 11:0 1 1024M 0 rom

      Below is an example of an NVMe disk. In this case the device name is nume0n1 and the partition numbers are p1 p2 p3 p4.

      # lsblk NAME MAT:MIN RM SIZE RO TYPE MOUNTPOINT nume0n1 259:0 0 4776 0 disk |-nume0n1p1 259:1 0 100M 0 part |-nume0n1p2 259:2 0 16M 0 part |-nume0n1p3 259:3 0 476.3G 0 part |-nume0n1p4 259:4 0 508M 0 part

      For the rest of this section we will assume you have a NVMe drive so we will use that naming convention. So we know the NVMe device name is nume0n1. Lets use the fdisk utility to remove all of the existing partitions on the disk. Don’t forget I mentioned this is a data destructive test.

      fdisk /dev/nume0n1

      Use the d command to remove all of the existing partitions on the disk. Then use the w command to write the blank partition table to disk. You can confirm the partitions are gone with the p command. Now finally create a new partition using the n then p primary, 1 first partition and then pick the defaults for the remainder. Now use the w write command to write the partitions to disk and the q command to quit fdisk. Finally ensure the OS is in sync with the disk by keying in sync twice at the FOS Linux command prompt.

      You can confirm your changes my once again using the lsblk command.

      # lsblk NAME MAT:MIN RM SIZE RO TYPE MOUNTPOINT nume0n1 259:0 0 4776 0 disk |-nume0n1p1 259:1 0 477.6G 0 part

      Now that we have our test partition we need to format it. Lets format this nvme first partition using this command.

      mkfs -t ext4 /dev/nvme0n1p1

      The output of this command should look similar to this

      # mkfs -t ext4 /dev/nvme0n1p1 nke2fs 1.45.6 (20-Mar-2020) Discarding device blocks: done Creating filesysten with 124866880 4k blocks and 31219712 inodes Filesysten UUID: 5652bad-814c-4a2d-811a-fd5fb50a6dc4 Superblock backups stored on blocks: 32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000, 7962624, 11239424, 20480000, 23887872, 71663616, 78675968, 102400000 Allocating group tables: done Writing inode tables: done Creating journal (262144 blocks): done Writing superblocks and filesystem accounting information: done

      Hang on we are almost done with the setup. The next step is to create a directory mount point and to connect the nvme partition to the directory mount point.

      mkdir /ntfs mount -t ext4 /dev/nvme0n1p1 /ntfs

      Issue the following command to confirm the partition is mounted.

      df -h Filesystem Size Used Avail Use% Mounted on /dev/root 248M 97M 139M 42% / /dev/nvme0n1p1 477G 26G 452G 6% /ntfs

      The line we are looking for is this one. It shows that the device /dev/nvme0n1p1 is connected to the /ntfs path.

      /dev/nvme0n1p1 477G 26G 452G 6% /ntfs

      Finally we’ve made it to the benchmarking point. Now we will use the dd command to create a 1GB file on the local disk.

      dd if=/dev/zero of=/ntfs/test1.img bs=1G count=1 oflag=direct 1+0 records in 1+0 records out 1073741824 bytes (1.1 GB, 1.0GiB) copied, 0.546232 s, 2.0 GB/s

      In this case the dd command created the 1GB file in about a 1/2 second at a rate of 2.0 GB/s. This results is withing the expected range.

      I can give you a few numbers off the top of my head that are reasonable results.
      SATA HDD (spinning disk) 40-90MB/s
      SATA SSD 350-520MB/s
      NVMe 950-3500MB/s

      If your results are within the above ranges for the selected storage device this part of the test was successful.

    • george1421G

      Imaging with FOG and Secure Boot (PoC)

      Tutorials
      • • • george1421
      6
      3
      Votes
      6
      Posts
      5.3k
      Views

      george1421G

      Preparing the FOG server with the prerequisites

      sudo apt-get update sudo apt-get upgrade -y

      Reboot the FOG server and then install the required packages

      sudo apt-get install -y openssl efitools gnu-efi git build-essential help2man libssl-dev sudo perl -e'use CPAN; install "File::Slurp"'

      Create the Secure Boot PKI infrastructure

      Lets create the working directories

      mkdir -p /opt/fog/secureboot/efikeys

      Now lets create our bash file to create the PKI infrastructure

      vi /opt/fog/secureboot/mkkeys.sh

      Insert the following text into that bash script.

      #!/bin/bash # Copyright (c) 2015 by Roderick W. Smith # Updated 26-Nov-2021 by George1421 for the FOG Project # Licensed under the terms of the GPL v3 NAME=FOGProjectSB openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME PK/" -keyout efikeys/PK.key \ -out efikeys/PK.crt -days 3650 -nodes -sha256 openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME KEK/" -keyout efikeys/KEK.key \ -out efikeys/KEK.crt -days 3650 -nodes -sha256 openssl req -new -x509 -newkey rsa:2048 -subj "/CN=$NAME DB/" -keyout efikeys/DB.key \ -out efikeys/DB.crt -days 3650 -nodes -sha256 openssl x509 -in efikeys/PK.crt -out efikeys/PK.cer -outform DER openssl x509 -in efikeys/KEK.crt -out efikeys/KEK.cer -outform DER openssl x509 -in efikeys/DB.crt -out efikeys/DB.cer -outform DER GUID=`python3 -c 'import uuid; print(str(uuid.uuid1()))'` echo $GUID > efikeys/myGUID.txt cert-to-efi-sig-list -g $GUID efikeys/PK.crt efikeys/PK.esl cert-to-efi-sig-list -g $GUID efikeys/KEK.crt efikeys/KEK.esl cert-to-efi-sig-list -g $GUID efikeys/DB.crt efikeys/DB.esl rm -f efikeys/noPK.esl touch efikeys/noPK.esl sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k efikeys/PK.key -c efikeys/PK.crt PK efikeys/PK.esl efikeys/PK.auth sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k efikeys/PK.key -c efikeys/PK.crt PK efikeys/noPK.esl efikeys/noPK.auth sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k efikeys/PK.key -c efikeys/PK.crt KEK efikeys/KEK.esl efikeys/KEK.auth sign-efi-sig-list -t "$(date --date='1 second' +'%Y-%m-%d %H:%M:%S')" \ -k efikeys/KEK.key -c efikeys/KEK.crt db efikeys/DB.esl efikeys/DB.auth chmod 0600 efikeys/*.key echo "" echo "" echo "For use with KeyTool, copy the *.auth and *.esl files to a FAT USB" echo "flash drive or to your EFI System Partition (ESP)." echo "For use with most UEFIs' built-in key managers, copy the *.cer files;" echo "but some UEFIs require the *.auth files." echo ""

      Make the script we just created executable
      Change into the secureboot directory and finally run the bash script.

      chmod a+x /opt/fog/secureboot/mkkeys.sh cd /opt/fog/secureboot/ ./mkkeys.sh

      I will tell you that when you run the mkkeys.sh you may get run time errors. You will need to research on your own what is missing and add that to your fog server using the apt-get package tool. I developed this process and a linux mint server and the duplicated it on a debian 10 fog server. I think I have all of the packages above that is needed. But YMMV.

      Create the Secure Boot signed enrollment boot loader

      Lets get the efitools package so we can built the enrollment bootloaders

      git clone git://git.kernel.org/pub/scm/linux/kernel/git/jejb/efitools.git

      Change into the efitools directory and run make to build the templates.

      cd /opt/fog/secureboot/efitools make

      I will tell you that when you run the make commandyou may get run time errors. You will need to research on your own what is missing and add that to your fog server’s environment using the apt-get package tool. I developed this process and a linux mint server and the duplicated it on a debian 10 fog server. I think I have all of the packages above that is needed. But YMMV.

      Now that we have the templates created we need to download the current secure boot key chains that are created by the hardware manufacture. My plan is to take the original certificate database, tack on the FOG certificates onto the end and then upload the combined certificates back to the target hardware. So for completeness I’ll show you how I downloaded the original certificates. To save you some time, I’ll include these files in a zip file a bit later in this post.

      For this bit one of my dev fog servers runs on real hardware. I used these commands under debian to extract these generic certificates from the target computer’s bios. The computer I extracted them from was a Dell Precision 3620. So these certificates and certificate store is fairly new.

      mkdir -p /opt/fog/secureboot/hwkeys cd /opt/fog/secureboot/ sudo efi-readvar -v PK -o /opt/fog/secureboot/hwkeys/hw_PK.esl sudo efi-readvar -v KEK -o /opt/fog/secureboot/hwkeys/hw_KEK.esl sudo efi-readvar -v db -o /opt/fog/secureboot/hwkeys/hw_db.esl sudo efi-readvar -v dbx -o /opt/fog/secureboot/hwkeys/hw_dbx.esl sudo chmod 666 /opt/fog/secureboot/hwkeys/*

      The following certificates (not really the correct word to use, but for my sanity I’ll call them certificates) are the only ones we are interested in (hw_KEK.esl, hw_db.esl, hw_dbx.esl). As I said above, you don’t need to do the above part because I’ll provide these generic certificates. note: 15-Dec-23 the hw_dbx.esl file might not be created if the dbx database is empty. If this is the case you should ignore the commands that use that file. Thank you @jfernandz for the updated inforamtion

      Now lets bring everything together

      cp /opt/fog/secureboot/efikeys/* /opt/fog/secureboot/efitools/ cp /opt/fog/secureboot/hwkeys/* /opt/fog/secureboot/efitools/ cd /opt/fog/secureboot/efitools mv DB.esl DB-fog.esl mv KEK.esl KEK-fog.esl mv dbx.esl dbx-fog.esl

      At this point we are going to take the hardware certificates we downloaded from the uefi firmware and tag the FOG certificates onto the end.

      cat hw_db.esl DB-fog.esl > DB.esl cat hw_KEK.esl KEK-fog.esl > KEK.esl cat hw_dbx.esl > dbx.esl

      Lets rebuild the signed boot loaders with the updated certificates

      rm LockDown*efi LockDown.so LockDown.o make cp LockDown-signed.efi EnrollKeys.efi

      /opt/fog/secureboot/efitools/EnrollKeys.efi is the boot loader we will use to auto insert the updated security keys into the uefi firmware. So lets copy that file to the /tftpboot

      cp /opt/fog/secureboot/efitools/EnrollKeys.efi /tftpboot

      The other two key files from this process that we will need is the FOG certificate private and public keys.

      /opt/fog/secureboot/efikeys/DB.crt
      /opt/fog/secureboot/efikeys/DB.key

      In the next post we will go through and sign all of the boot files needed to secure boot into FOG.

      Sample download with certificates
      Here are the microsoft certificates that I downloaded from my Dell Desktop computer running debian. If you want this file you will need to download it and change the extension to .zip from .txt to be able to extract the contents. These keys are not unique, serialized, or unique. Every computer that is secure boot capable have these default keys installed.

      ms_hwcerts.zip.txt

    • george1421G

      Updating/Compiling the latest version of iPXE

      Tutorials
      • • • george1421
      5
      1
      Votes
      5
      Posts
      13.2k
      Views

      JJ FullmerJ

      @george1421 https://docs.fogproject.org/en/latest/compile_ipxe_binaries
      Just throwing in the permalink to the doc on this process.

    • george1421G

      FOG 1.5.9.57 on Debian 10 mysql root password is blank

      Bug Reports
      • • • george1421
      6
      0
      Votes
      6
      Posts
      786
      Views

      S

      @tom-elliott said in FOG 1.5.9.57 on Debian 10 mysql root password is blank:

      We are a fully clean install. Meaning no packages except git are installed. No Apache, php, or MySQL. Why should the installer ask for root password here? It has never been setup before this point. There would be no password. FOG, in my opinion, should not be defining the root user password here either.

      I think it should force the user to have a DB root password unless it’s a setup with local socket access as described below. That was one of the major points of re-writing that part of the installer. I tested a lot and would hope that the installer does what I say on all officially supported systems.

    • george1421G

      Raspberry Pi 4 unable to pxe boot

      Bug Reports
      • • • george1421
      7
      0
      Votes
      7
      Posts
      1.7k
      Views

      Jacques-OlivierJ

      @george1421 I am looking for a way to easely clone (for backup) the data on several PIs

    • george1421G

      Feature request for FOG 1.6.x - Support GRUB as UEFI exit mode

      Feature Request
      • • • george1421
      8
      1
      Votes
      8
      Posts
      1.5k
      Views

      george1421G

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

    • george1421G

      Feature request for FOG 1.6.x - Install RTC Class Driver in FOS Kernel

      Feature Request
      • • • george1421
      1
      1
      Votes
      1
      Posts
      311
      Views

      No one has replied

    • george1421G

      Feature request for FOG 1.6.x - Add firwall support to FOG installer on FOG Server

      Feature Request
      • • • george1421
      9
      0
      Votes
      9
      Posts
      863
      Views

      Wayne WorkmanW

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

    • george1421G

      Feature request for FOG 1.6.x - Configure image capture to use NFSv4 instead of NFSv3

      Feature Request
      • • • george1421
      30
      1
      Votes
      30
      Posts
      6.8k
      Views

      george1421G

      @hancocza Its a bit complicated, but the short answer is that the inits will need to be updated to support NFSv4 then its needs to be paired with the current kernel. You will have this issue with usb booting or booting via PXE. The default inits don’t support nfsv4. The answer is they can be fixed.

      @Developers can we enable the inits to be compiled with NFSv4 support but not update the scripts to include NFSv4 support. This way the FOG Admin can just unpack, add the settings and repack the inits because everything would be already compiled in. Or simply include my hack below to enable a kernel variable to enable nfsv4 and only have one master inits package.

    • george1421G

      Feature request for FOG 1.6.x - FOG Installer instll DNSMASQ

      Feature Request
      • • • george1421
      6
      2
      Votes
      6
      Posts
      711
      Views

      S

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

    • george1421G

      Feature request for FOG 1.6.x - FOG Installer revise question order

      Feature Request
      • • • george1421
      1
      3
      Votes
      1
      Posts
      221
      Views

      No one has replied

    • george1421G

      Feature request for FOG 1.6.x - Add option to bypass bitlocker check

      Feature Request
      • • • george1421
      1
      0
      Votes
      1
      Posts
      239
      Views

      No one has replied

    • george1421G

      Feature request for FOG 1.6.x - Change database format from ISAM to INNODB

      Feature Request
      • • • george1421
      4
      0
      Votes
      4
      Posts
      417
      Views

      Tom ElliottT

      Let me clarify, it turns off the limitation preventing the update to move all tables to innodb.

    • george1421G

      Feature request for FOG 1.6.x - Change default mysql date from invalid 00/00/0000

      Feature Request
      • • • george1421
      2
      0
      Votes
      2
      Posts
      253
      Views

      Tom ElliottT

      Fog 1.6 already does this.

    • george1421G

      Feature request for FOG 1.6.x - Scheduled database maintenance

      Feature Request
      • • • george1421
      8
      1
      Votes
      8
      Posts
      634
      Views

      S

      @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;
    • george1421G

      Feature request for FOG 1.6.x - Break out API engine from WebUI

      Feature Request
      • • • george1421
      7
      1
      Votes
      7
      Posts
      727
      Views

      Wayne WorkmanW

      The API and UI could be separated while still using the same port. The virtualhost config would look something like this:

      <VirtualHost *:80> ServerName dev.localhost DocumentRoot /home/projects/smk/cms ErrorLog /var/log/apache2/smk-cms-error.log </VirtualHost> <VirtualHost *:80> ServerName my-project.localhost DocumentRoot /home/projects/smk/deploy ErrorLog /var/log/apache2/smk-deploy-error.log </VirtualHost>

      Reference:
      https://stackoverflow.com/questions/6069892/different-virtualhosts-with-the-same-port

      If this separation were done, I would think the installer could ask you if you want to install the API (defaulting to yes) and ask if you want to install the UI (defaulting to yes). This would allow the admin to break stuff apart.

      I also think the database portion should be broken out, and the installer should ask if you want to install that or not (defaulting to yes).

      There should be installation arguments for these things too.

      Also, not wanting to delay 1.6 as noted by others. I would like to see this separation in a later release. As George has noted, if these things are separated it becomes easier to work on each one independently, meaning the learning curve to contribute is lower. Particularly with using popular frameworks.

      Just my 2 cents.

    • george1421G

      Feature request for FOG 1.6.x - Move WebUI to HTTPS protocol

      Feature Request
      • • • george1421
      4
      1
      Votes
      4
      Posts
      364
      Views

      S

      @george1421 We use the certificate store. Though this is something else I was hoping to change in the future because Mono on Linux and Mac OS X have a long history of issues with the certificate store and we might think about keeping the certs just in files on the disk. I have not had the time to think this through. Might be a dead road…

    • george1421G

      Feature request for FOG 1.6.x - Replace NFSv3

      Feature Request
      • • • george1421
      35
      0
      Votes
      35
      Posts
      5.0k
      Views

      george1421G

      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

    • 1 / 1