Re: rsync and filesystem capabilities
On Thu, 10 Jan 2019, Russell Coker wrote: > On Wednesday, 9 January 2019 12:14:47 PM AEDT Tim Connors via luv-main wrote: > > rsync flags I frequently see people forget to use on rsync when they want > > the destination to be exactly the same as the source: > > > > rsync -HAXS > > Thanks Tim and Glenn. Not surprising that rsync could do what I wanted but I > just didn't know where to look. Guess what bit me today when another senior admin moved a bastion host over to its new location? Fortunately, thanks to you, this was fresh in my memory and I knew exactly where to look. I took the opportunity of making it a teachable moment. I still haven't convinced the storage admins of same yet though. -- Tim Connors ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: rsync and filesystem capabilities
On Wednesday, 9 January 2019 12:14:47 PM AEDT Tim Connors via luv-main wrote: > On Wed, 9 Jan 2019, Glenn McIntosh wrote: > > On 8/1/19 11:44 pm, Russell Coker via luv-main wrote: > > > Below is an example. Is there a good way of preserving capabilities > > > apart > > > from running "getcap /bin/* /sbin/* /usr/bin/* /usr/sbin/*" and storing > > > the > > > output? > > > > Since the capabilities are stored using extended attributes, then using > > the '-X' flag on rsync should do the trick. You may need to be root user > > to be able to create these on the destination (or alternatively use > > fake-super on rsync). > > rsync flags I frequently see people forget to use on rsync when they want > the destination to be exactly the same as the source: > > rsync -HAXS Thanks Tim and Glenn. Not surprising that rsync could do what I wanted but I just didn't know where to look. getfattr from the attr package on debian can give a list of xattrs that are in use. # getfattr -m - /bin/ping getfattr: Removing leading '/' from absolute path names # file: bin/ping security.capability security.selinux -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Grub in text mode
On Thursday, 10 January 2019 2:57:02 AM AEDT Craig Sanders via luv-main wrote: > On Tue, Jan 08, 2019 at 11:51:33PM +1100, Russell Coker wrote: > > Currently I run my kvm VMs under screen > > sounds like a PITA doing everything manually...but whatever works for you. Well it's a small ongoing PITA vs a major PITA to change to something else... > > and just use screen -r to get the console. > > I strongly recommend switching to tmux. I stuck with screen for many years, > been using it since the early 90s, but finally made the switch about a year > ago...finally got sick of screen's bugs, quirks, piss-poor unicode support, > and effective abandonment as an actively-developed project. it took me > about half an hour to configure it so that the transition was > non-traumatic. after a few days, i wouldn't even consider switching back, > any more than i'd switch back from mutt to elm. People have been saying that for years. But what I do with screen is fairly basic so it's been working well enough that I haven't had a great incentive to change. > As I did with screen, I've mapped tmux's escape key to ^K. I rarely use > that for anything else but I use ^A all the time -- ^A is move to start of > line in bash/readline, an extremely stupid key for screen to hijack as its > default control prefix. tmux's default of ^B is better, but I've got used > to ^K over the years. Unlearning that would be too painful. Yes, ^A is really annoying. But I don't use screen enough to make it worth changing. > > Virsh has some benefits, but so far it hasn't seemed worth the pain. > > for just "virsh console", no not worth it. for everything else - virsh and > libvirt are definitely worth it. I probably will do it eventually. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Many to many VPN
On Thursday, 10 January 2019 5:59:42 PM AEDT Mike O'Connor wrote: > > Support is required for Linux servers and Linux, Windows, and OS/X > > clients. > > Wireguard :) Possibly not the most user friendly but very impressive tech. https://en.wikipedia.org/wiki/WireGuard I have had some experience with Wireguard. It requries kernel code that isn't in the mainline kernel so you need DKMS to get it going, that doesn't exclude it, but makes it a little more difficult. According to Wikipedia one of the benefits of WG is that it has less code, but some of that code is kernel code so the potential for problems if there's a problem is greater. Another cited benefit of WG is not being as difficult as IPSEC, but pretty much everything meets the "not as difficult as IPSEC" criteria. How does WG go for many-many operation? -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Many to many VPN
On 10/1/19 5:11 pm, russ...@coker.com.au wrote: > If you have servers in multiple countries and people using those servers in > multiple locations what's a good way of setting up a VPN? > > If you have a VPN server at each DC then performance will be great but users > have to setup multiple instances of the VPN software which they will mess up > and time will be wasted. > > If you have a VPN server at one DC then a user who connects to a server in a > different DC gets longer ping times. Also an outage in one DC breaks > everything. > > Any ideas? > > Support is required for Linux servers and Linux, Windows, and OS/X clients. > Wireguard :) Possibly not the most user friendly but very impressive tech. Mike ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Many to many VPN
If you have servers in multiple countries and people using those servers in multiple locations what's a good way of setting up a VPN? If you have a VPN server at each DC then performance will be great but users have to setup multiple instances of the VPN software which they will mess up and time will be wasted. If you have a VPN server at one DC then a user who connects to a server in a different DC gets longer ping times. Also an outage in one DC breaks everything. Any ideas? Support is required for Linux servers and Linux, Windows, and OS/X clients. -- My Main Blog http://etbe.coker.com.au/ My Documents Bloghttp://doc.coker.com.au/ ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
Re: Grub in text mode
On Tue, Jan 08, 2019 at 11:51:33PM +1100, Russell Coker wrote: > Currently I run my kvm VMs under screen sounds like a PITA doing everything manually...but whatever works for you. > and just use screen -r to get the console. I strongly recommend switching to tmux. I stuck with screen for many years, been using it since the early 90s, but finally made the switch about a year ago...finally got sick of screen's bugs, quirks, piss-poor unicode support, and effective abandonment as an actively-developed project. it took me about half an hour to configure it so that the transition was non-traumatic. after a few days, i wouldn't even consider switching back, any more than i'd switch back from mutt to elm. As I did with screen, I've mapped tmux's escape key to ^K. I rarely use that for anything else but I use ^A all the time -- ^A is move to start of line in bash/readline, an extremely stupid key for screen to hijack as its default control prefix. tmux's default of ^B is better, but I've got used to ^K over the years. Unlearning that would be too painful. > Virsh has some benefits, but so far it hasn't seemed worth the pain. for just "virsh console", no not worth it. for everything else - virsh and libvirt are definitely worth it. craig -- craig sanders ___ luv-main mailing list luv-main@luv.asn.au https://lists.luv.asn.au/cgi-bin/mailman/listinfo/luv-main
