[gentoo-user] Re: default CONFIG_PROTECT behavior
On 2018-06-19 19:40, Kai Peter wrote: > In general the usage of sdiff is terrible to me. So I did my own > solution. Unfortunately it is not ready to publish it, but if it is > perhaps of interest to you have a look at > http://gentoo.dyndn.es/doku.php/utils:qrtconf. This page describes > mainly the concept and isn't really finished. If it would be worth to > give it a try to you let me know and I will share it. For me it works > since a few years with some development. I'll definitely take a look soon. Thanks! -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Tue, Jun 19, 2018 at 1:02 PM, Grant Taylor wrote: > On 06/19/2018 05:57 AM, Mick wrote: >> >> Actually, I don't know if there is a way to set up multiple nameservers >> for corresponding name resolution in/out of the tunnel, without using a >> domain- specific override as you would with dnsmasq and without leaking DNS >> queries to the ISP if you are meant to be querying the tunnel's nameservers. > > > My go to solution would be a local DNS server that decides where different > queries go. That's what NM does. It uses dnsmasq. (Maybe not by default but that's how I've got it running.) >> Yes, those VPN implementations that set up separate routing policy tables >> help to keep main and 'VPN' rules separate, which is neat and easy to >> maintain. only contains the route from the local VPN subnet to the remote >> LAN subnet. > > > Yep. > >> Quite. The user (or his VPN client via some NM plugin) is meant to add in >> this networkmanager IPv4/Route tab the remote LAN subnet(s) and enable "Use >> only for resources on this connection" in order to set up a split tunnel. >> Then tun0 will only be used to tunnel connections to these subnets. All >> other connections to the Internet or local LAN will go outside the tunnel, >> using the default local gateway. > > > *nod* > >> Given Hilco's results I'm surmising an empty table in the NM translates as >> 0.0.0.0/0 and all connections end up being routed via the VPN stack, but I >> could be wrong because I don't know what he may have entered in this table. > > Agreed. Originally, I had nothing in there. Adding the one route (see my email on June 7th) makes it working ... mostly. >> Yes, but leaving the routes table empty ... it seems to tunnel everything >> through it ... I don't know without trying it out myself or getting more >> info on the settings. > > > Ya. This is unexpected behavior to me. I also don't have a convenient way > to reproduce it. > >> I expect you can set up a subnet here and from this the NM will configure >> the route accordingly to make it go through the VPN stack. > > > That is the expected behavior. > > IMHO the lack of additional routes mean that nothing other than the VPN link > itself should be routed through the VPN. > >> Is this something I can manipulate via resolv.conf on the local PC >> (without a local resolver) to make sure DNS searches meant for the VPN stack >> are tunneled to the remote nameservers not leaked outside it? > > > I don't know of a good way to do this without a local DNS server. > >> PS. Thanks for your write up on network namespaces. I'll look into this >> in more depth when I get a minute, because I would like to contain/isolate >> desktop applications I inherently mistrust - e.g. Skype. > > > You're welcome. I'm glad to hear people benefiting from it. Feel free to > reach out if you have any questions. Thanks for discussing this. At minimum it's quite interesting. :-)
Re: [gentoo-user] slot conflict for media-libs/x264-0.0
On Mon, Jun 18 2018, Mick wrote: > On Monday, 18 June 2018 21:28:38 BST allan gottlieb wrote: >> On Mon, Jun 18 2018, Mick wrote: >> > Hi Allan, >> > >> > On Monday, 18 June 2018 18:52:31 BST allan gottlieb wrote: >> >> On Sun, Jun 17 2018, Mick wrote: >> >> > On Sunday, 17 June 2018 22:04:50 BST allan gottlieb wrote: >> >> >> (I have been offline for a few months and apologize if this has been >> >> >> covered.) >> >> >> >> >> >> I had not synced for about 3 months (fear of new, incompatible >> >> >> gnucash) >> >> >> but have now done so. Unsurprisingly my normal update world shows >> >> >> many >> >> >> entries and also unsurprising is a blocker (slot conflict). >> > >> > As a first step I suggest you go through the 'eselect news read new'. >> > >> > There was a profile change sometime late last year. The profile change >> > enews is important and you should deal with it first. It is titled: >> > >> > 'New 17.0 profiles in the Gentoo repository' >> > >> > and it involves updating gcc as part of it and perhaps changing your >> > profile if it is due to be deprecated. >> >> I had done the upgrade to 17.0 months ago. >> 17.1 is unstable so I believe 17.0 is the right profile for me. >> >> > Once you've been through all this give it another spin, but use >> > --backtrack=99 to see if portage resolves the conflicts. >> >> backtrack=99 didn't change the situation, but adding in addition >> --autounmask-backtrack=y did! > > Interesting! What did it autounmask? That is not what the option does. It just prevents backtracking from stopping earlier when it finds that config changes are needed. With the full backtrack=99 all the serious problems were resolved, I just needed to add a use setting, specifically grub[mount]. >> > I can't see a [B] in the list you provided, all are small blocks [b] which >> > portage will deal with on its own. >> >> The list I provided was for my update world. That has little b's. The >> only blockage I have is the slot conflict I mentioned originally. The >> big B's happened when I tried >> >>emerge -1pDv media-video/ffmpeg > > Well, media-libs/x264-0.0.20130506 is no longer in the tree. media-video/ > ffmpeg-3.3.6 does not require it and works fine with media-libs/ > x264-0.0.20160712. This is why I suggested that manual removal and update > earlier on. > > Unless something else is blocking ffmpeg (you've got a long update list there > which might influence it) there shouldn't be a problem with my suggested > workaround. Nevertheless, getting portage to pontificate and resolve the > dependency graph is invariably a safer option. ;-) By just adding --backtrack=99 --autounmask-backtrack=y portage was happy (and so am I). Indeed, considering I hadn't synced for 3 months, I consider myself lucky and will try to do at least weekly emerge --update @world's thanks, allan
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/19/2018 05:57 AM, Mick wrote: Actually, I don't know if there is a way to set up multiple nameservers for corresponding name resolution in/out of the tunnel, without using a domain- specific override as you would with dnsmasq and without leaking DNS queries to the ISP if you are meant to be querying the tunnel's nameservers. My go to solution would be a local DNS server that decides where different queries go. Yes, those VPN implementations that set up separate routing policy tables help to keep main and 'VPN' rules separate, which is neat and easy to maintain. only contains the route from the local VPN subnet to the remote LAN subnet. Yep. Quite. The user (or his VPN client via some NM plugin) is meant to add in this networkmanager IPv4/Route tab the remote LAN subnet(s) and enable "Use only for resources on this connection" in order to set up a split tunnel. Then tun0 will only be used to tunnel connections to these subnets. All other connections to the Internet or local LAN will go outside the tunnel, using the default local gateway. *nod* Given Hilco's results I'm surmising an empty table in the NM translates as 0.0.0.0/0 and all connections end up being routed via the VPN stack, but I could be wrong because I don't know what he may have entered in this table. Agreed. Yes, but leaving the routes table empty ... it seems to tunnel everything through it ... I don't know without trying it out myself or getting more info on the settings. Ya. This is unexpected behavior to me. I also don't have a convenient way to reproduce it. I expect you can set up a subnet here and from this the NM will configure the route accordingly to make it go through the VPN stack. That is the expected behavior. IMHO the lack of additional routes mean that nothing other than the VPN link itself should be routed through the VPN. Is this something I can manipulate via resolv.conf on the local PC (without a local resolver) to make sure DNS searches meant for the VPN stack are tunneled to the remote nameservers not leaked outside it? I don't know of a good way to do this without a local DNS server. PS. Thanks for your write up on network namespaces. I'll look into this in more depth when I get a minute, because I would like to contain/isolate desktop applications I inherently mistrust - e.g. Skype. You're welcome. I'm glad to hear people benefiting from it. Feel free to reach out if you have any questions. -- Grant. . . . unix || die
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
On 2018-06-19 17:15, Ian Zimmerman wrote: On 2018-06-18 11:34, Rich Freeman wrote: Oh, the other tool you'll want to use is etckeeper to manage /etc in a git repo and auto-commit changes/etc with package manager hooks. That is a cross-distro tool, and will save your butt if you mess something up. I already do this, only without any packaging/wrapping like etckeeper, just bare git. It's why I want to skip all the the gentoo merge thingies, get a crack at the updated file shipped with a package, insert this into git on a parallel branch, then merge in the git way. Not sure that it could solve your issue ... but I wrote a tool that - at least for me - solves all the issues with etc-update and friends. In general the usage of sdiff is terrible to me. So I did my own solution. Unfortunately it is not ready to publish it, but if it is perhaps of interest to you have a look at http://gentoo.dyndn.es/doku.php/utils:qrtconf. This page describes mainly the concept and isn't really finished. If it would be worth to give it a try to you let me know and I will share it. For me it works since a few years with some development. Kai -- Sent with eQmail-1.11 beta
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
On Tue, Jun 19, 2018 at 11:15 AM Ian Zimmerman wrote: > > On 2018-06-18 11:34, Rich Freeman wrote: > > > Oh, the other tool you'll want to use is etckeeper to manage /etc in a > > git repo and auto-commit changes/etc with package manager hooks. That > > is a cross-distro tool, and will save your butt if you mess something > > up. > > I already do this, only without any packaging/wrapping like etckeeper, > just bare git. It's why I want to skip all the the gentoo merge > thingies, get a crack at the updated file shipped with a package, insert > this into git on a parallel branch, then merge in the git way. > Yeah, that certainly works, and if you're disciplined it has the advantage that your git history will always be clean and reliable. The advantage of etckeeper is the PM hooks. If you have uncommitted changes in /etc when you run emerge it will just dump them all into an auto-described commit so that you don't end up with a big pile of modified files with no history. If you always manually review all your changes and commit them dutifully after every update, then I believe etckeeper should behave as one big NOOP. It really only kicks in if you're lazy about committing your changes, to ensure that they don't pile up. Then if you have an issue you can at least look at the changes since the last time you ran emerge, or the time before that, and so on. Personally I use a hybrid approach. When I go deliberately modifying config files I make my own clean commits with the stuff I know is good. Then I let etckeeper just merge in the daily cruft that I'm not really intentionally touching anyway. That means that the commits with real descriptions are known-good, and the rest are potentially-useful snapshots I can make use of if they work. But, this is all at home - I'd be more disciplined on a system I cared about. Well, then again on a system I cared about I'd probably be using ansible or whatever and not upgrading in-place anyway. -- Rich
[gentoo-user] Re: default CONFIG_PROTECT behavior
On 2018-06-18 11:34, Rich Freeman wrote: > Oh, the other tool you'll want to use is etckeeper to manage /etc in a > git repo and auto-commit changes/etc with package manager hooks. That > is a cross-distro tool, and will save your butt if you mess something > up. I already do this, only without any packaging/wrapping like etckeeper, just bare git. It's why I want to skip all the the gentoo merge thingies, get a crack at the updated file shipped with a package, insert this into git on a parallel branch, then merge in the git way. -- Please don't Cc: me privately on mailing lists and Usenet, if you also post the followup to the list or newsgroup. To reply privately _only_ on Usenet and on broken lists which rewrite From, fetch the TXT record for no-use.mooo.com.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
On Monday, 18 June 2018 15:37:00 BST Grant Taylor wrote: > On 06/18/2018 04:30 AM, Mick wrote: > > The above does not offer him a route into the company's LAN and he cannot > > connect to the servers *.i.company.com. > > Small nuance that routes don't deal with names and that names must be > translated to IPs. But that does require making sure there are routes > to the proper name server to do said translation. Yes, domain name resolution for remote hosts within the remote LAN space has to happen before routing to an IP address takes place. If these remote machines are not publicly accessible, Hilco's PC will need to have configured his company's nameservers. Some (all?) VPN clients use scripts to achieve this once a connection with the remote peer has taken place. Many distros use dnsmasq to set up separate nameservers for split tunnels. With Gentoo (without dnsmasq) I have found the remote peer's nameservers are written in resolv.conf by the VPN client Up script, but only for full tunnels. I've noticed with strongswan when setting up split tunnels it errors out as it tries to set a nameserver for the tunnel side and ends up with the local default gateway nameserver only. Of course remote peer private name space resolutions fail, because the local nameserver does not know anything about them. Actually, I don't know if there is a way to set up multiple nameservers for corresponding name resolution in/out of the tunnel, without using a domain- specific override as you would with dnsmasq and without leaking DNS queries to the ISP if you are meant to be querying the tunnel's nameservers. > > When the above setting is left disabled, then Hilco can access the company > > domain, but not the Internet - a full tunnel. His route table now shows > > tun0 as being the default NIC: > > It seems like you're using "full tunnel" to mean that everything is > routed through the tunnel. Save for the VPN tunnel traffic itself. > > I figured that's what you meant, but I wanted to ask and be sure. > > > My understanding of a "split tunnel" or "split horizon" as you call it > > involves two routes: > > > > 1. Route for connections via the VPN tunnel: > > > > One route is used to direct datagrams from a local subnet or a virtual > > VPN IP allocated by the remote VPN gateway, e.g. $SOME_COMPANY_IP_1, > > via the VPN tunnel (tun0) to the remote company's LAN. > > > > 2. Route for all other connections, outside the VPN tunnel: > > > > A second route is typically the default route of the PC for all other > > connections and it is used to route datagrams outside the VPN tunnel. > > Agreed. Though there may be more routes for additional subnets routed > through the VPN. This is what I think Hilco is wanting to do. > > > Some VPN clients add a new routing policy rule table (e.g. strongswan), > > but others (e.g. racoon) add routes for the VPN tunnel in the main > > routing policy rule table. > > I was not aware that any VPNs used alternate routing tables and rules to > use them. But that does make sense. Programmatically, that may be > simpler to maintain and clean up after the VPN is shut down too. I.e. > assume that anything in the routing table is for the VPN and safe to > remove, along with the single predictable rule referencing said table. Yes, those VPN implementations that set up separate routing policy tables help to keep main and 'VPN' rules separate, which is neat and easy to maintain. >From memory Strongswan in particular sets up a rule table with ID 220, which only contains the route from the local VPN subnet to the remote LAN subnet. > > In contrast, a "full tunnel" directs all outgoing datagrams from any > > local subnet via the VPN. > > I agree at a high level. The nuanced nitpicks don't matter at this point. > > > I appreciate what I describe above is inverse to what the setting "Use > > only for resources on this connection" is meant to do, but I merely go > > by the route tables Hilco has provided. > > My not-yet-awake brain doesn't see the inverse issue that you're > referring to. But I'm used to dealing with VPNs, so maybe something is > instinctive for me. > > > Hmm ... prompted by your question in this post I had to give it a second > > thought, and I've come up with this hypothesis: > > > > IF no specific subnet routes are defined on the NM routes tab AND the "Use > > only for resources on this connection" is selected, then it may be that > > networkmanager translates no subnet entry to mean 0.0.0.0/0 - ALL routes > > will be tunneled via the VPN, leaving nothing for the default route. > > Using a (translated or not) route of "0.0.0.0/0" seems antithetical to > "Use only for resources on this connection". Quite. The user (or his VPN client via some NM plugin) is meant to add in this networkmanager IPv4/Route tab the remote LAN subnet(s) and enable "Use only for resources on this connection" in order to set up a split tunnel. Then tun0 will only be
