Re: [gentoo-user] Enable "regular" network traffic when using VPN
On 06/17/2018 03:05 PM, Mick wrote: TBH I wouldn't select "Use only for resources on this connection", I thought "Use only for resources on this connection" would enable (what I know as) "split horizon", which is what I thought the OP wanted to do. In other words route company traffic through the VPN and route everything not to the company via the ISP. because this creates a full tunnel. What does "full tunnel" mean to you? I would think that it's the same tunnel, just different traffic routed through it. -- Grant. . . . unix || die
[gentoo-user] Re: default CONFIG_PROTECT behavior
On 2018-06-17 18:12, Mick wrote: > From the fine manual: > > z Zap (delete) the new config file and continue. So what do you do if the merge of this file is too hard and you want to do it another time? The answer seems to be q (quit) or n (next), but _nothing_ in the documentation says this is safe. > For files which have a lot of changes, some of which I wish to reject > and some to accept, I tend to use m (for merging). Again from the > fine manual: > > m Interactively merge the current and new config files. The problem (or multiple problems) here is that it doesn't say what is being merged into what (no, its not symmetric), and to compound that it doesn't just leave this file alone and quit or go on to the next file; it shows some diff again. What does this new diff mean? I can't make sense of it without answering my other questions. To clarify: I don't think this is simply a usability problem that can be addressed by using better or more verbose English. I think there is a "big picture", a concept of what is being done, and this concept has not found its way into the documentation or the UI itself. In particular, I suspect the developers think of it as merging my mods into the "official" packaged versions, while I want to handle it the other way: I see my version as the "master" or "trunk", and I want to merge the package mods into it. But I really don't know. I am confused :-P -- 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] Re: default CONFIG_PROTECT behavior
On Sunday, 17 June 2018 18:12:11 BST Mick wrote: > On Sunday, 17 June 2018 18:08:48 BST Ian Zimmerman wrote: > > On 2018-06-17 12:42, Andrew Udvare wrote: > > > On 06/17/2018 12:17 PM, Ian Zimmerman wrote: > > > > What happens to files within the scope of CONFIG_PROTECT if I don't > > > > execute dispatch-conf or any similar thingy? I have found the > > > > confusion the latter tool generates completely unsurmountable. > > > > > > I think the side-by-side merger is very easy for small changes. Most > > > of the time I press z because I don't need the new changes. > > > > It's not the merge step itself (sdiff) that is confusing, it's what > > dispatch-conf does afterward with the result. When you used it the > > first time, did you understand what "zap new" means? > > From the fine manual: > > z Zap (delete) the new config file and continue. > > > For files which have a lot of changes, some of which I wish to reject and > some to accept, I tend to use m (for merging). Again from the fine manual: > > m Interactively merge the current and new config files. > > > And yes, I was driven to ask this after I got an update that wasn't > > "small". > > > > > find /etc/ -iname '._cfg*' > > > > > > Or what dispatch-conf does: > > > > > > find /etc -iname '._cfg_*' ! -name '.*~' ! -iname '.*.bak' -print > > > > Thanks for this information. I don't have any of those problems. I still use etc-update, and if there are complex updates I edit the original file myself, using the diff as a guide. I never did get to grips with the more "modern" ways of doing it. -- Regards, Peter.
Re: [gentoo-user] slot conflict for media-libs/x264-0.0
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). However, I > am confused by the message which reads > > !!! Multiple package instances within a single package slot have been pulled > !!! into the dependency graph, resulting in a slot conflict: > > media-libs/x264:0 > > (media-libs/x264-0.0.20170701:0/152::gentoo, ebuild scheduled for merge) > pulled in by (no parents that aren't satisfied by other packages in this > slot) > > (media-libs/x264-0.0.20160712:0/148::gentoo, installed) pulled in by > > >=media-libs/x264-0.0.20130506:0/148=[abi_x86_64(-)] > > required by (media-video/ffmpeg-3.3.6:0/55.57.57::gentoo, installed) > > Why is this a conflict since the first one 0/152 seems to permit other > solutions. Is the (unstated) point that the second one 0/148 is not one > of the acceptable "other packages in this slot". > > Also I seem some advice. Should I be first working on this blockage. > Or should I instead try to deal with some of the easy updates. > > thanks in advance, > allan Since you have the latest ffmpeg installed, this is how I would go about this: emerge --depclean -a -v media-libs/x264 emerge -1aDv '=media-libs/x264-0.0.20170701' emerge -1aDv media-video/ffmpeg -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Enable "regular" network traffic when using VPN
Hilco, I don't know if this thread was resolved - additional suggestions posted below. On Saturday, 9 June 2018 01:20:18 BST Hilco Wijbenga wrote: > Let me give some more information, perhaps that will help. > > Setup without VPN > $ ip route > default via 192.168.151.1 dev eth0 proto static metric 100 > 127.0.0.0/8 via 127.0.0.1 dev lo > 192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric > 100 > > (192.168.151.1 is my own gateway, an old computer functioning as router) > > > Setup with VPN (Gateway: vpn.company.com; Other DNS Servers: > dns1,dns2; Search Domains: > r1.i.company.com,r2.i.company.com,r3.i.company.com,r4.i.company.com,r5.i.com > pany.com,r6.i.company.com,r7.i.company.com,r8.i.company.com,i.company.com,co > nfig) > $ ip route > default via 192.168.151.1 dev eth0 proto static metric 100 > $SOME_COMPANY_IP_1 dev tun0 proto kernel scope link src > $SOME_COMPANY_IP_1 metric 50 > 127.0.0.0/8 via 127.0.0.1 dev lo > 192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric > 100 > 192.168.151.1 dev eth0 proto static scope link metric 100 > $VPN_GATEWAY via 192.168.151.1 dev eth0 proto static metric 100 > > (where $SOME_COMPANY_IP is the IP of some internal server, and > $VPN_GATEWAY is the IP of vpn.company.com). > ==> This does _not_ allow me to access (e.g.) *.i.company.com but > everything else works fine. In the above setup you need to define a route for the subnet of your company's LAN. For example, if the LAN of your company is 10.0.20.0/24: ip route add 10.0.20.0/24 via $SOME_COMPANY_IP_1 dev tun0 should push all connections to your company's LAN via the tunnel tun0. Two commands to help you see what routes your VPN client is setting up are: ip rule list which may list some new tables (in addition to local, main and default), if your VPN client has set these up. Then look at the contents of said table, e.g.: ip route show table 220 Not all clients create separate rules, so the changes may have been added to the main rule table. If in doubt and don't mind some noise look at all the tables: ip route show table all NOTE: If you are accessing your company's LAN/servers using a FQDN instead of private IP addresses, then you will need to configure the appropriate nameserver for your company. Check what has been entered in /etc/resolv.conf. > Same setup but without "Use only for resources on this connection": > $ ip route > default dev tun0 proto static scope link metric 50 Device tun0 has a higher metric than your physical eth0 device below. I expect all connections which can be routed via tun0 will be routed so. > default via 192.168.151.1 dev eth0 proto static metric 100 I'm not sure if this will work, but you can try changing the metric of device eth0, so it takes precedence to tun0; e.g.: ip route replace default via 192.168.151.1 dev eth0 proto static metric 30 ip route show ip route delete default via 192.168.151.1 dev eth0 proto static metric 100 > $SOME_COMPANY_IP_2 dev tun0 proto kernel scope link src > $SOME_COMPANY_IP_2 metric 50 > 127.0.0.0/8 via 127.0.0.1 dev lo > 192.168.151.0/24 dev eth0 proto kernel scope link src 192.168.151.103 metric > 100 > 192.168.151.1 dev eth0 proto static scope link metric 100 > $VPN_GATEWAY via 192.168.151.1 dev eth0 proto static metric 100 > > (note that $SOME_COMPANY_IP_1 and $SOME_COMPANY_IP_2 differ only in > the last digit; this seems to go up by one every time I connect to > VPN, so probably irrelevant) > ==> This allows me to access *.i.company.com but breaks everything else. I expect it breaks everything else (connections to anything outside you company's LAN) because everything is sent out tun0 which has a higher priority than your eth0, but your company's routing on the other side, once it receives the packets, does not allow outgoing connections from your allocated $SOME_COMPANY_IP_2 to the Internet. TBH I wouldn't select "Use only for resources on this connection", because this creates a full tunnel. > What would be the "correct" output for "ip route"? Different VPN clients create rules and entries in different tables, so there isn't a straight forward "correct" ip route output. In any case, using 'ip route show table all' you should be able to see a route which allows connections to your company's LAN subnet to be sent out via tun0 and connections to the rest of the world to be routable via your eth0. What VPN client are you using? -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] slot conflict for media-libs/x264-0.0
(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). However, I am confused by the message which reads !!! Multiple package instances within a single package slot have been pulled !!! into the dependency graph, resulting in a slot conflict: media-libs/x264:0 (media-libs/x264-0.0.20170701:0/152::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (media-libs/x264-0.0.20160712:0/148::gentoo, installed) pulled in by >=media-libs/x264-0.0.20130506:0/148=[abi_x86_64(-)] required by (media-video/ffmpeg-3.3.6:0/55.57.57::gentoo, installed) Why is this a conflict since the first one 0/152 seems to permit other solutions. Is the (unstated) point that the second one 0/148 is not one of the acceptable "other packages in this slot". Also I seem some advice. Should I be first working on this blockage. Or should I instead try to deal with some of the easy updates. thanks in advance, allan
Re: [gentoo-user] Re: default CONFIG_PROTECT behavior
On Sunday, 17 June 2018 18:08:48 BST Ian Zimmerman wrote: > On 2018-06-17 12:42, Andrew Udvare wrote: > > On 06/17/2018 12:17 PM, Ian Zimmerman wrote: > > > What happens to files within the scope of CONFIG_PROTECT if I don't > > > execute dispatch-conf or any similar thingy? I have found the > > > confusion the latter tool generates completely unsurmountable. > > > > I think the side-by-side merger is very easy for small changes. Most > > of the time I press z because I don't need the new changes. > > It's not the merge step itself (sdiff) that is confusing, it's what > dispatch-conf does afterward with the result. When you used it the > first time, did you understand what "zap new" means? >From the fine manual: z Zap (delete) the new config file and continue. For files which have a lot of changes, some of which I wish to reject and some to accept, I tend to use m (for merging). Again from the fine manual: m Interactively merge the current and new config files. > And yes, I was driven to ask this after I got an update that wasn't > "small". > > > find /etc/ -iname '._cfg*' > > > > Or what dispatch-conf does: > > > > find /etc -iname '._cfg_*' ! -name '.*~' ! -iname '.*.bak' -print > > Thanks for this information. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: default CONFIG_PROTECT behavior
On 2018-06-17 12:42, Andrew Udvare wrote: > On 06/17/2018 12:17 PM, Ian Zimmerman wrote: > > What happens to files within the scope of CONFIG_PROTECT if I don't > > execute dispatch-conf or any similar thingy? I have found the > > confusion the latter tool generates completely unsurmountable. > I think the side-by-side merger is very easy for small changes. Most > of the time I press z because I don't need the new changes. It's not the merge step itself (sdiff) that is confusing, it's what dispatch-conf does afterward with the result. When you used it the first time, did you understand what "zap new" means? And yes, I was driven to ask this after I got an update that wasn't "small". > find /etc/ -iname '._cfg*' > > Or what dispatch-conf does: > > find /etc -iname '._cfg_*' ! -name '.*~' ! -iname '.*.bak' -print Thanks for this information. -- 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] default CONFIG_PROTECT behavior
On 06/17/2018 12:17 PM, Ian Zimmerman wrote:
> What happens to files within the scope of CONFIG_PROTECT if I don't
> execute dispatch-conf or any similar thingy? I have found the confusion
> the latter tool generates completely unsurmountable.
I think the side-by-side merger is very easy for small changes. Most of
the time I press z because I don't need the new changes.
> What I'd prefer is the debian behavior: the package supplied config file
> is simply saved under a mangled name (*.dpkg-dist alongside the real
> file on debian) and I'm left to merge the changes at my convenience,
> with my preferred tools.
You are free to do that. The files are named alongside the real files,
and they start with '._cfg'. Before I knew about dispatch-conf,
sometimes I would do:
for i in ._cfg*; do mv "$i" "${i/._cfg}"; done
>
> So that's my question in a nutshell: after emerge but before
> dispatch-conf, where are the new versions of config files?
>
find /etc/ -iname '._cfg*'
Or what dispatch-conf does:
find /etc -iname '._cfg_*' ! -name '.*~' ! -iname '.*.bak' -print
--
Andrew
signature.asc
Description: OpenPGP digital signature
[gentoo-user] default CONFIG_PROTECT behavior
What happens to files within the scope of CONFIG_PROTECT if I don't execute dispatch-conf or any similar thingy? I have found the confusion the latter tool generates completely unsurmountable. What I'd prefer is the debian behavior: the package supplied config file is simply saved under a mangled name (*.dpkg-dist alongside the real file on debian) and I'm left to merge the changes at my convenience, with my preferred tools. And maybe that's what portage already does, but I'm not sure. If yes, where is the package supplied file saved? Is it under /etc/config-archive? The wiki makes the impression that /etc/config-archive is specific to dispatch-conf. So that's my question in a nutshell: after emerge but before dispatch-conf, where are the new versions of config files? -- 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.
[gentoo-user] Network problem when rebooting Fedora qemu/kvm guest on Gentoo host
Hello, I have some problem with some of my qemu/kvm guests running Fedora on a Gentoo host where my Gentoo guests works without problem. The problem that I have is that when I reboot (shutdown -r now) the Fedora guest "loses" (ifconfig does not show a IP-address) their network connections. The Gentoo guests reboots without problem. All the guests have same HW-configuration, only Name/DiskImage/MAC- addresses differ. Here some technical details: Host: DistributionGentoo Kernel 4.9.95-gentoo Qemuapp-emulation/qemu-2.11.1-r2 USE="aio bzip2 caps curl fdt filecaps gnutls jpeg lzo ncurses nls pin-upstream-blobs png sdl seccomp vhost-net vnc xattr" QEMU_SOFTMMU_TARGETS="x86_64" QEMU_USER_TARGETS="x86_64" libvirt app-emulation/libvirt-4.3.0 USE="caps dbus libvirtd nls qemu udev" Guest DistributionFedora 28 Kernel 4.16.15-300.fc28.x86_64 Networkmanager NetworkManager.x86_64 1:1.10.8-1.fc28 Any suggestions? -- Dan Johansson *** This message is printed on 100% recycled electrons! *** 0x17EB372A2FB894AD.asc Description: application/pgp-keys smime.p7s Description: S/MIME Cryptographic Signature
