Re: [CentOS] scp via another server
Hi, This is fairly common. I would look into the use of a proxy command to do exactly what you ask. In addition, though not strictly necessary, I also would generally recommend rsync rather than scp*. Both of these are documented on my page here: http://www2.physics.ox.ac.uk/it-services/central-ssh-access Its got an Oxford Physics specific slant to it but hopefully its helpful. *I don't think rsync has any issue when the remote machine prints things either. Sean On 13 Jun 2016 7:26 pm, "H" wrote: > On June 12, 2016 8:51:42 PM CEST, cpol...@surewest.net wrote: > >On 2016-06-12 19:07, H wrote: > >> On 06/12/2016 05:21 PM, J Martin Rushton wrote: > >> > -BEGIN PGP SIGNED MESSAGE- > >> > Hash: SHA1 > >> > > >> > $ scp svr2:/path/to/source svr1:/path/to/dest > >> > > >> > You'll get twice the network traffic since the copy is running on > >your > >> > workstattoin (or whatever). > >> > > >> > On 12/06/16 15:40, H wrote: > >> > > I normally use ssh to log into a remote server, change directory > >> > > and then use scp from there to copy files from another remote > >> > > server to the first one. > >> > > > >> > > Now the first server has been hit by continuous error correction > >> > > messages from the ECC controller, all of which are corrected, and > >I > >> > > am unable to get a command line to issue the required commands to > >> > > change directory and then run scp from the other server. I have > >no > >> > > problems, however, getting into the first server - except for > >being > >> > > drowned by the error correction messages and the server seems to > >be > >> > > running "fine". > >> > > > >> > > Until I am able to get to the server and investigate, is it > >> > > possible to accomplish the above on a single command line, thus > >> > > avoiding seeing the error messages? I should add that both the > >> > > first and second server are set up to accept keys and not > >passwords > >> > > so at least I don't have to worry about that. > > > >Try changing kernel console log level to 0, possibly: > > > > echo '0 0 0 0' > /proc/sys/kernel/printk > > > >should take effect instantly. You _might_ be able to do this > >remotely via ssh. Also possibly can do via magic sysrq + 0. > > > >(see: RHEL 6 Deployment Guide (rev 3.1 2011-05-19) Appendix C > >pp.537-538) > > > >HTH, HAND, > >-- > >Charles Polisher > > > >___ > >CentOS mailing list > >CentOS@centos.org > >https://lists.centos.org/mailman/listinfo/centos > > Tried it but did not work since I am not root... > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Mounting NFS subdirectories individually or just the parent?
There is a slight performance related reason for exporting disk partitions individually, the performance boost is server-side as Paul says. The advantage is that the no_subtree_check can be used without any additional security risk. It is probably the case that the /export/base/a is a partition, is exported with no_subtree_check, and therefore there is a small performance boost. Preventing server side mount point traversal can also form part of a security mechanism if servers have different security options for different mount points, but in this case mounting server:/export/base wouldn't give you the same client view of the filesystem tree as mounting each individually if it worked at all. Cheers, Sean On 27 July 2016 at 23:21, Paul Heinlein wrote: > On Wed, 27 Jul 2016, Frank Thommen wrote: > > Hello, >> >> does it in any respect (throughput/performance, cpu load, I/O load, >> resilience, ...) matter, if one mounts subdirectories of an NFS (v3) export >> into separate directories or if one just mounts the parent directory? >> >> I.e. like this: >> >> server: /export/base/a -> /mnt/a >> server: /export/base/b -> /mnt/b >> server: /export/base/c -> /mnt/c >> server: /export/base/d -> /mnt/d >> server: /export/base/e -> /mnt/e >> >> or simply like this: >> >> server:/export/base -> /mnt >> > > Performance wise, any bottleneck will almost certainly be tied to the > disks on the back end, not the nfs process itself. > > There are a couple good reasons for splitting up the mounts: > > 1. They can have different export restrictions (e.g., for different >client hosts, ro vs. rw permissions, user squashing). > > 2. /base/[a-e] live on different RAID arrays and might benefit from >different management cycles; that'd also be a case where multiple >exports might be a good idea. That said, I've never managed an >exported filesystem consisting of different arrays; we've always >exported at the RAID level or below. > > -- > Paul Heinlein <> heinl...@madboa.com <> http://www.madboa.com/ > ___ > CentOS mailing list > CentOS@centos.org > https://lists.centos.org/mailman/listinfo/centos > ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
