I have a kickstart server I use to build Rocky 9 images with. After I do an image, I copy a folder full of setup scripts over to the new machine using scp.
This has been working fine up until yesterday, when I began using mini-ssd drives instead of SATA drives.
Now the scp transfers frequently stall on some files, and freeze for a long time, but then it’s like whatever is locking the file let’s it loose and the file transfers just like normal. If I leave it long enough, it eventually transfers everything. (I never had this issue when using SATA drives)
The kickstart server is running CentOS 7 - the image it’s pushing is Rocky 9.0.
The switch connecting the two machines is a small 5 port gigabit switch. When the kickstart server is pushing out the image during the install, everything is smooth and fast.
It does seem to stall on some specific files but other files in the same folder with the same permissions and ownership don’t have a problem.
I’m stumped on this one. Any ideas?
The actual command I’m running is:
scp -l 8192 -r root@10.0.0.1:/files/ /
What is “mini-ssd”? (There are also both HDD and SSD SATA drives, and some SSD SATA drives are in M.2 form factor.)
I have used rsync for ages (but one would need to install it in the kickstart in order to use it), so can’t say about scp other than it is somewhat deprecated due to some security issues.
I have also shifted to the use of Ansible as “setup script” (it does in practice copy scripts and run them on the remote). It can also be idempotent; make changes only when needed, i.e. can be run multiple times. RHEL (and thus Rocky too) has rhel-system-roles, which Red Hat has documentation for; “roles” for Ansible to configure/maintain some systems.
Why Rocky 9.0? One should now install 9.2 (as it is more up to date starting point and the only currently supported version of Rocky 9).
“mini-ssd” = those little 1 inch square M2 drives
So, do you have any suggestions as to why SCP is failing?
If this question was of interest to anyone, it was one of those “duh” moments. I was thinking firewalld was disabled and it wasn’t. After disabling firewalld, the transfers worked fine (although it’s kind of weird why some files got through and others didn’t when firewalld was enabled)
Indeed. The default ruleset:
- Does not filter outgoing traffic
- Does allow incoming replies, i.e. traffic of existing connections
- Does allow incoming new ssh connections
The scp does use ssh, so one should be able to connect from outside
and the transfer is in “existing connection”. If there were a long pause
in traffic, then the connection could perhaps time out, but a continuous
transfer does not have such pauses?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.