[gentoo-user] Multiple package instances within a single package slot
Hi there! Some may remember me from posting here often. But since a year, I have a new life, and much less time for sitting at my computer. Sigh. And my beloved Gentoo got a little outdated. So, a @world update does not work. I thought I give emerge -e @world a try, this should sort out the problems, but this also does not go well. I don't want to bother you with the whole lot of output emerge gives me, and just ask a specific question at the moment. I get the 'Multiple package instances within a single package slot have been pulled into the dependency graph, resulting in a slot conflict' message, and several affected packages. One example is claws: mail-client/claws-mail:0 (mail-client/claws-mail-3.9.0-r1::gentoo, ebuild scheduled for merge) pulled in by ~mail-client/claws-mail-3.9.0 required by (mail-client/claws-mail-address_keeper-1.0.7::gentoo, ebuild scheduled for merge) (mail-client/claws-mail-3.9.2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) Looking at the ebuild, I see that claws-mail-address_keeper rdepends on claws-mail-3.9.0. But being on ~amd86, 3.9.2 would be current. I can solve this by masking versions greater than 3.9.0. Two questions: Why can't portage deal with this itself, and simply install the highest version that fulfills all requirements? And how do I notice an update to claws-mail-address_keeper that would allow a newer version of claws-mail? Other than remembering those masks and go through them once in a while? Similar problems happen with sys-boot/syslinux, pulled in by sys-boot/unetbootin, media-sound/jack-audio-connection-kit, pulled in by app-emulation/emul-linux-x86-soundlibs, and all dev-qt packages, where I did not yet figure out what to do. I am running portage 2.2.7. Alex
Re: [gentoo-user] Multiple package instances within a single package slot
On 04/10/2013 12:50, Alex Schuster wrote: Hi there! Some may remember me from posting here often. But since a year, I have a new life, and much less time for sitting at my computer. Sigh. And my beloved Gentoo got a little outdated. So, a @world update does not work. I thought I give emerge -e @world a try, this should sort out the problems, but this also does not go well. I don't want to bother you with the whole lot of output emerge gives me, and just ask a specific question at the moment. I get the 'Multiple package instances within a single package slot have been pulled into the dependency graph, resulting in a slot conflict' message, and several affected packages. One example is claws: mail-client/claws-mail:0 (mail-client/claws-mail-3.9.0-r1::gentoo, ebuild scheduled for merge) pulled in by ~mail-client/claws-mail-3.9.0 required by (mail-client/claws-mail-address_keeper-1.0.7::gentoo, ebuild scheduled for merge) (mail-client/claws-mail-3.9.2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) Looking at the ebuild, I see that claws-mail-address_keeper rdepends on claws-mail-3.9.0. But being on ~amd86, 3.9.2 would be current. No, that is not the right assumption. Portage doesn't guess what versions are dependencies, it reads the ebuild and does exactly what the ebuild says. The ebuild for claws-mail-address_keeper say it depends on ~claws-mail-3.9.0, that means any revision of 3.9.0. Portage *must not* decide to use 3.9.1 or 3.9.2, because the ebuild has clearly told it not to. The solution is to get the maintainer to bump the DEPENDS for that plugin, or to use claws-mail-3.9.0, or to stop using that plugin. emerge output is confusing. The last line you quoted is just portage telling you that 3.9.2 would normally be the choice it would make, but the lines above it says it's going to pick 3.9.0 instead,a nd why I can solve this by masking versions greater than 3.9.0. Two questions: No you can't. That will just produce different blockers Why can't portage deal with this itself, and simply install the highest version that fulfills all requirements? See above. It could deal with it if the ebuild didn't tell it something different And how do I notice an update to claws-mail-address_keeper that would allow a newer version of claws-mail? Other than remembering those masks and go through them once in a while? emerge -avuND world will tell you when updates are available Similar problems happen with sys-boot/syslinux, pulled in by sys-boot/unetbootin, media-sound/jack-audio-connection-kit, pulled in by app-emulation/emul-linux-x86-soundlibs, and all dev-qt packages, where I did not yet figure out what to do. Often with a box that is a while out of date, it is easier to just unmerge blocking packages and add them back in. I've had this with Qt more than once. I am running portage 2.2.7. Alex -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Switch to VT1 on shutdown fails with mesa = 9.1
Since I don't know the cause and didn't find a way to debug this, here are the symptoms: Ever since media-libs/mesa = 9.1 went stable I had the problem, that the switch from Xfce on VT7 back to VT1 on shutdown fails. The screen goes black and does not show anything, but the system halts as normal. It is not possible to switch to VT1 by keyboard while the shutdown is still in progress when this has happened. I can't find anything in the Xorg or other log files according to this problem. Can't find anything related in Gentoo bugzilla or searching the web... The problem always disappeared by downgrading to mesa 9.1, but that now requires other packages to be downgraded too, so I'd like to resolve this. It is an AMD64 system with an ATI Barts PRO [Radeon HD 6850] using KMS, desktop session with Xfce started by x11-misc/lightdm. Any hints on how to debug this problem would be highly appreciated. Andreas
Re: [gentoo-user] Switch to VT1 on shutdown fails with mesa = 9.1
On 04/10/2013 13:20, Andreas Prieß wrote: Since I don't know the cause and didn't find a way to debug this, here are the symptoms: Ever since media-libs/mesa = 9.1 went stable I had the problem, that the switch from Xfce on VT7 back to VT1 on shutdown fails. The screen goes black and does not show anything, but the system halts as normal. It is not possible to switch to VT1 by keyboard while the shutdown is still in progress when this has happened. I can't find anything in the Xorg or other log files according to this problem. Can't find anything related in Gentoo bugzilla or searching the web... The problem always disappeared by downgrading to mesa 9.1, but that now requires other packages to be downgraded too, so I'd like to resolve this. It is an AMD64 system with an ATI Barts PRO [Radeon HD 6850] using KMS, desktop session with Xfce started by x11-misc/lightdm. Any hints on how to debug this problem would be highly appreciated. I've had a few things similar tot his happen to me over the years. Strangely, each time it has been framebuffer and related settings in the kernel config! (mostly incompatible options selected) What do you have in your kernel config? -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Multiple package instances within a single package slot
On 04/10/2013 11:50, Alex Schuster wrote: Hi there! Some may remember me from posting here often. But since a year, I have a new life, and much less time for sitting at my computer. Sigh. And my beloved Gentoo got a little outdated. So, a @world update does not work. I thought I give emerge -e @world a try, this should sort out the problems, but this also does not go well. I don't want to bother you with the whole lot of output emerge gives me, and just ask a specific question at the moment. I get the 'Multiple package instances within a single package slot have been pulled into the dependency graph, resulting in a slot conflict' message, and several affected packages. One example is claws: mail-client/claws-mail:0 (mail-client/claws-mail-3.9.0-r1::gentoo, ebuild scheduled for merge) pulled in by ~mail-client/claws-mail-3.9.0 required by (mail-client/claws-mail-address_keeper-1.0.7::gentoo, ebuild scheduled for merge) (mail-client/claws-mail-3.9.2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) Looking at the ebuild, I see that claws-mail-address_keeper rdepends on claws-mail-3.9.0. But being on ~amd86, 3.9.2 would be current. I can solve this by masking versions greater than 3.9.0. Two questions: Why can't portage deal with this itself, and simply install the highest version that fulfills all requirements? Your use of --emptytree makes it slightly harder to determine from the above output, because the conflict messages will not correctly distinguish merged (installed) packages from those that are yet to be merged. Do you have mail-client/claws-mail-address_keeper in your world file? If so, that would mandate its installation as part of the @world set (no if or buts). In turn, that would exhibit a hard dependency on claws-mail-3.9.0, which obviously cannot co-exist with 3.9.2, even if you have unmasked it. Try removing the entry from the world file if it's there, then seeing whether the conflict is handled any differently. And how do I notice an update to claws-mail-address_keeper that would allow a newer version of claws-mail? Other than remembering those masks and go through them once in a while? As of the 3.9.1 ebuild, there is a comment above the collection of blocks that states: Plugins are all integrated or dropped since 3.9.1 Further, from the 3.9.1 release notes: All plugins previously packaged as 'Extra Plugins' are now contained within the Claws Mail package. Thus, it's possible that the address_keeper plugin has been folded into the core. In turn, that would explain why it must block the plugin as a separate package. Similar problems happen with sys-boot/syslinux, pulled in by sys-boot/unetbootin, media-sound/jack-audio-connection-kit, pulled in by app-emulation/emul-linux-x86-soundlibs, and all dev-qt packages, where I did not yet figure out what to do. I am running portage 2.2.7. Alex
Re: [gentoo-user] Multiple package instances within a single package slot
On Fri, 04 Oct 2013 12:50:51 +0200, Alex Schuster wrote: mail-client/claws-mail:0 (mail-client/claws-mail-3.9.0-r1::gentoo, ebuild scheduled for merge) pulled in by ~mail-client/claws-mail-3.9.0 required by (mail-client/claws-mail-address_keeper-1.0.7::gentoo, ebuild scheduled for merge) (mail-client/claws-mail-3.9.2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) Looking at the ebuild, I see that claws-mail-address_keeper rdepends on claws-mail-3.9.0. But being on ~amd86, 3.9.2 would be current. Claws Mail plugins are now part of the main ebuild, upstream moved them into the main tarball with their building handled by ./configure. If you unmerge all plugins, claws-mail should update and build whichever plugins your USE flags desire. -- Neil Bothwick I am Speedy Gonzales of Borg: Prepare to be accelerated! signature.asc Description: PGP signature
Re: [gentoo-user] Switch to VT1 on shutdown fails with mesa = 9.1
On 04.10.2013 13:44, Alan McKinnon wrote: On 04/10/2013 13:20, Andreas Prieß wrote: Since I don't know the cause and didn't find a way to debug this, here are the symptoms: Ever since media-libs/mesa = 9.1 went stable I had the problem, that the switch from Xfce on VT7 back to VT1 on shutdown fails. The screen goes black and does not show anything, but the system halts as normal. It is not possible to switch to VT1 by keyboard while the shutdown is still in progress when this has happened. I can't find anything in the Xorg or other log files according to this problem. Can't find anything related in Gentoo bugzilla or searching the web... The problem always disappeared by downgrading to mesa 9.1, but that now requires other packages to be downgraded too, so I'd like to resolve this. It is an AMD64 system with an ATI Barts PRO [Radeon HD 6850] using KMS, desktop session with Xfce started by x11-misc/lightdm. Any hints on how to debug this problem would be highly appreciated. I've had a few things similar tot his happen to me over the years. Strangely, each time it has been framebuffer and related settings in the kernel config! (mostly incompatible options selected) What do you have in your kernel config? The kernel is manually compiled from gentoo hardened-sources-3.11.3 with PAX and GRSEC enabled for desktop system, RBAC disabled. (The system runs stable packages with the kernel being one of very few exceptions.) In the Graphics support section just two things are enabled manually, the rest is automatically selected: CONFIG_DRM and CONFIG_DRM_RADEON. This results in the following (unset options shortened): # Graphics support # CONFIG_AGP is not set CONFIG_VGA_ARB=y CONFIG_VGA_ARB_MAX_GPUS=16 # CONFIG_VGA_SWITCHEROO is not set CONFIG_DRM=y CONFIG_DRM_KMS_HELPER=y # CONFIG_DRM_LOAD_EDID_FIRMWARE is not set CONFIG_DRM_TTM=y # I2C encoder or helper chips CONFIG_DRM_RADEON=y # CONFIG_DRM_RADEON_UMS is not set CONFIG_HDMI=y CONFIG_FB=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y # Frame buffer hardware drivers # CONFIG_BACKLIGHT_LCD_SUPPORT is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # Console display driver support CONFIG_VGA_CONSOLE=y # CONFIG_VGACON_SOFT_SCROLLBACK is not set CONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_LOGO is not set Anything else relevant in the kernel?
Re: [gentoo-user] Switch to VT1 on shutdown fails with mesa = 9.1
On 04.10.2013 13:20, Andreas Prieß wrote: Since I don't know the cause and didn't find a way to debug this, here are the symptoms: Ever since media-libs/mesa = 9.1 went stable I had the problem, that the switch from Xfce on VT7 back to VT1 on shutdown fails. The screen goes black and does not show anything, but the system halts as normal. It is not possible to switch to VT1 by keyboard while the shutdown is still in progress when this has happened. I can't find anything in the Xorg or other log files according to this problem. Can't find anything related in Gentoo bugzilla or searching the web... The problem always disappeared by downgrading to mesa 9.1, but that now requires other packages to be downgraded too, so I'd like to resolve this. It is an AMD64 system with an ATI Barts PRO [Radeon HD 6850] using KMS, desktop session with Xfce started by x11-misc/lightdm. Any hints on how to debug this problem would be highly appreciated. Maybe this is relevant... Xorg is running a dual head layout using xinerama instead of randr. Composite disabled since it does not work with this config.
Re: [gentoo-user] Switch to VT1 on shutdown fails with mesa = 9.1
On 04/10/2013 14:39, Andreas Prieß wrote: On 04.10.2013 13:20, Andreas Prieß wrote: Since I don't know the cause and didn't find a way to debug this, here are the symptoms: Ever since media-libs/mesa = 9.1 went stable I had the problem, that the switch from Xfce on VT7 back to VT1 on shutdown fails. The screen goes black and does not show anything, but the system halts as normal. It is not possible to switch to VT1 by keyboard while the shutdown is still in progress when this has happened. I can't find anything in the Xorg or other log files according to this problem. Can't find anything related in Gentoo bugzilla or searching the web... The problem always disappeared by downgrading to mesa 9.1, but that now requires other packages to be downgraded too, so I'd like to resolve this. It is an AMD64 system with an ATI Barts PRO [Radeon HD 6850] using KMS, desktop session with Xfce started by x11-misc/lightdm. Any hints on how to debug this problem would be highly appreciated. Maybe this is relevant... Xorg is running a dual head layout using xinerama instead of randr. Composite disabled since it does not work with this config. Your kernel config in the other reply looks fine to me. This dual head setup - do you have one large desktop across two monitors, or two screens configured in xorg.conf? I can never quite remember what xinerama does (I think it's the first one) Can you reproduce the problem using just one configured monitor? -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Mantle Open source GPU engine
Howdy one and all, Well I heard about about AMD's push, referred to as Mantle to unseat DirectX as the defacto gaming platform (yawn)... But recently, an egg_head mathematician that irritates me from time to time, called me in the middle of the night. He, being an eceptionally bright and difficult humnoid; would not shut up at what AMD is doing. Finally it seems that an open source, raw hardware access API is going to allow truely unfettered access to the computational blocks inside of a GPU. (ok now I was awake). Upon googing this am, I do see quite a buzz, particularly since all Nvidia would have to do, is decide to implement the open source -- open standard access to the bare metal of the GPU. This should not be taken likely as it is akin to all of the FPGA hardware folks giving away the billions of dollars in IP, software and integration tools that make building a custom processor, possible. Those tools are locked away, due to expense and the business approach of hardware vendors asking for money each time they reveal the tricks, trade secrets and heuritical methods to build low level components. What this means is that MANTLE is a game changer and opens up bare metal access to multitudes of ordinary computational and recreatioal computer weenies(whoa Pee!) If this is true, it is a GAME CHANGERS (could not resist the pun). So: A. it is time for me to dig into this issue. B. Are any of the folks on this list working to get Mantle support available on Gentoo? C. Anyone tested one of the Hawaii radeon cards? D. Anyone working on running SteamOS virtualize on (gentoo) linux? as always, your thoughts are most welcome James [1] http://www.pcworld.com/article/2049369/amd-nvidia-ramp-up-linux-driver-support-after-valves-steamos-announcement.html [2] http://www.tomshardware.com/news/amd-mantle-api-gcn-battlefield-4,24418.html
Re: [gentoo-user] Multiple package instances within a single package slot
Kerin Millar writes: On 04/10/2013 11:50, Alex Schuster wrote: [...] (mail-client/claws-mail-3.9.0-r1::gentoo, ebuild scheduled for merge) pulled in by ~mail-client/claws-mail-3.9.0 required by (mail-client/claws-mail-address_keeper-1.0.7::gentoo, ebuild scheduled for merge) (mail-client/claws-mail-3.9.2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) Looking at the ebuild, I see that claws-mail-address_keeper rdepends on claws-mail-3.9.0. But being on ~amd86, 3.9.2 would be current. I can solve this by masking versions greater than 3.9.0. Two questions: Why can't portage deal with this itself, and simply install the highest version that fulfills all requirements? Your use of --emptytree makes it slightly harder to determine from the above output, because the conflict messages will not correctly distinguish merged (installed) packages from those that are yet to be merged. I get some more errors without --emptytree (media-libs/x264, dev-libs/icu, dev-libs/boost, app-text/poppler, dev-util/boost-build, dev-lang/ocaml, x11-base/xorg-server), so I gave -e a try. Do you have mail-client/claws-mail-address_keeper in your world file? Sure. If so, that would mandate its installation as part of the @world set (no if or buts). In turn, that would exhibit a hard dependency on claws-mail-3.9.0, which obviously cannot co-exist with 3.9.2, even if you have unmasked it. Right. Try removing the entry from the world file if it's there, then seeing whether the conflict is handled any differently. I guess this would install 3.9.2, as there's no reason not to do this. And how do I notice an update to claws-mail-address_keeper that would allow a newer version of claws-mail? Other than remembering those masks and go through them once in a while? As of the 3.9.1 ebuild, there is a comment above the collection of blocks that states: Plugins are all integrated or dropped since 3.9.1 Further, from the 3.9.1 release notes: All plugins previously packaged as 'Extra Plugins' are now contained within the Claws Mail package. Thus, it's possible that the address_keeper plugin has been folded into the core. In turn, that would explain why it must block the plugin as a separate package. Good catch! Thanks, also to Neil. I unmerged this plugin, and claws updates just fine. Well. Sort of. Emerge also wanted to re-merge libreoffice, I have no idea why. The same happened yesterday when I upgraded portage. Whatever :) This time, I used --exclude app-office/libreoffice to avoid this. Alex
Re: [gentoo-user] Mantle Open source GPU engine
On Fri, Oct 04, 2013 at 03:02:07PM +, James wrote: Howdy one and all, Well I heard about about AMD's push, referred to as Mantle to unseat DirectX as the defacto gaming platform (yawn)... But recently, an egg_head mathematician that irritates me from time to time, called me in the middle of the night. He, being an eceptionally bright and difficult humnoid; would not shut up at what AMD is doing. Finally it seems that an open source, raw hardware access API is going to allow truely unfettered access to the computational blocks inside of a GPU. (ok now I was awake). Upon googing this am, I do see quite a buzz, particularly since all Nvidia would have to do, is decide to implement the open source -- open standard access to the bare metal of the GPU. This should not be taken likely as it is akin to all of the FPGA hardware folks giving away the billions of dollars in IP, software and integration tools that make building a custom processor, possible. Those tools are locked away, due to expense and the business approach of hardware vendors asking for money each time they reveal the tricks, trade secrets and heuritical methods to build low level components. What this means is that MANTLE is a game changer and opens up bare metal access to multitudes of ordinary computational and recreatioal computer weenies(whoa Pee!) If this is true, it is a GAME CHANGERS (could not resist the pun). So: A. it is time for me to dig into this issue. B. Are any of the folks on this list working to get Mantle support available on Gentoo? C. Anyone tested one of the Hawaii radeon cards? D. Anyone working on running SteamOS virtualize on (gentoo) linux? as always, your thoughts are most welcome James [1] http://www.pcworld.com/article/2049369/amd-nvidia-ramp-up-linux-driver-support-after-valves-steamos-announcement.html [2] http://www.tomshardware.com/news/amd-mantle-api-gcn-battlefield-4,24418.html computer gaming (yawn)... -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] Network failed and weird error message
Sometime last night while I was sleeping, my network sort of hiccuped. If I went to a Konsole, I could ping google so it appears the network was working on the lower level but not one browser that was left open would work. It also didn't/couldn't download new emails. When I restarted the browser, it worked. This is the case for both Seaminkey and Firefox. If it was just one, I'd think browser issue but not two of them at the same time. This is a example of what is in my messages file: Sep 29 03:10:15 localhost kernel: [382175.585718] ohci_hcd :00:12.1: urb 88034092b0c0 path 1 ep1in 9312 cc 9 -- status -121 Sep 29 03:10:17 localhost kernel: [382177.582033] ohci_hcd :00:12.1: urb 8803f06a9d40 path 1 ep1in 9212 cc 9 -- status -121 Sep 29 03:10:19 localhost kernel: [382179.586285] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9312 cc 9 -- status -121 Sep 29 03:10:21 localhost kernel: [382181.582602] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9212 cc 9 -- status -121 Sep 29 03:10:23 localhost kernel: [382183.586879] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9312 cc 9 -- status -121 I did a google search but obviously not direct hits so I had to adjust things until I got some hits. I removed for example the time stamp and lots of other unigue things to my system. The closest hit I got was three years ago and it's not the same even allowing for the stuff that will change. So, google was no help. I did a update last night. It updated the kernel sources but I haven't touched it yet. It updated the virtual for udev and nvidia-drivers which I am using at the moment. The only one I see that could possibly affect this is the udev one but I don't think it is likely since it is a virtual and the actual dev package didn't change. By the way, I use checkrestart after updates. If needed, I go to boot runlevel and restart whatever else is needed to get a clean output. I did rmmod nvidia and modprobe nvidia last night. I'm hoping this driver will not cause my kicker thingy to lock up like the last dozen or so has. :/ Keep in mind, the network worked in a Konsole. It appears to me it was KDE and/or things running inside of KDE and a regular user that had issues. I only checked my Seamonkey and Firefox and they did not work until they was restarted. My grand fix was to log out and log back in again. I just checked again, I am still getting the errors above even tho the browsers are working. The error above may not be related to this. Sort of confusing at the moment. Kernel problem? KDE problem? Some USB error? Something else? Thoughts? Dale :-) :-) P. S. This is what I get while restarting my network service: Oct 4 10:27:13 localhost kernel: [839575.429674] ohci_hcd :00:12.1: urb 8802f06dc240 path 1 ep1in 9312 cc 9 -- status -121 Oct 4 10:27:15 localhost kernel: [839577.425964] ohci_hcd :00:12.1: urb 8802f06dc240 path 1 ep1in 9212 cc 9 -- status -121 Oct 4 10:27:17 localhost kernel: [839579.430267] ohci_hcd :00:12.1: urb 8802f06dc6c0 path 1 ep1in 9312 cc 9 -- status -121 Oct 4 10:27:17 localhost sshd[8316]: Received signal 15; terminating. Oct 4 10:27:17 localhost kernel: [839580.289194] r8169 :03:00.0 eth0: link down Oct 4 10:27:17 localhost kernel: [839580.289204] r8169 :03:00.0 eth0: link down Oct 4 10:27:17 localhost kernel: [839580.289256] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Oct 4 10:27:18 localhost sshd[8692]: Server listening on 0.0.0.0 port 22. Oct 4 10:27:18 localhost sshd[8692]: Server listening on :: port 22. Oct 4 10:27:19 localhost kernel: [839581.426532] ohci_hcd :00:12.1: urb 88042086ac00 path 1 ep1in 9212 cc 9 -- status -121 Oct 4 10:27:19 localhost kernel: [839582.327590] r8169 :03:00.0 eth0: link up Oct 4 10:27:19 localhost kernel: [839582.327599] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Oct 4 10:27:21 localhost kernel: [839583.430811] ohci_hcd :00:12.1: urb 8802f06dc6c0 path 1 ep1in 9312 cc 9 -- status -121 Oct 4 10:27:22 localhost kernel: [839584.527264] r8169 :03:00.0 eth0: link down Oct 4 10:27:23 localhost kernel: [839585.427127] ohci_hcd :00:12.1: urb 880410612900 path 1 ep1in 9212 cc 9 -- status -121 Oct 4 10:27:23 localhost kernel: [839586.105999] r8169 :03:00.0 eth0: link up Oct 4 10:27:25 localhost kernel: [839587.431380] ohci_hcd :00:12.1: urb 880410612900 path 1 ep1in 9312 cc 9 -- status -121 Oct 4 10:27:27 localhost kernel: [839589.427672] ohci_hcd :00:12.1: urb 880410612900 path 1 ep1in 9212 cc 9 -- status -121 I'm thinking the error is not related to network since on e of them is while the network was down. I'm glad that logrotate is working well. O_O -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-user] Re: Where to put advanced routing configuration?
On 2013-10-03, Kerin Millar kerfra...@fastmail.co.uk wrote: On 03/10/2013 20:27, Grant Edwards wrote: Let's say you wanted to configure routing of TCP packets based on destination port like in this example: http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html [which contains a series of 'ip' and 'iptables' commands to get packets destined for port 25 to use a specific gateway.] How do do this the right way on a Gentoo system? [Where to put iptables and ip routing config/commands] The iptables runscript is ideal for persisting the rules. However, during the initial construction of a non-trivial ruleset, I prefer to write a script that adds the rules. An elegant way of doing this is to use iptables-restore with a heredoc. The method - and its advantages - are described in this document (section 3): http://inai.de/documents/Perfect_Ruleset.pdf Excellent reference. What about the 'ip' commands required to set up the tables, routes, and rules? Do those go in a startup script somewhere? Does one just edit /etc/iproute2/rt_tables by hand? One would assume route configuration belongs I would use the files under /etc/iproute2 for their intended purpose and a postup() hook in conf.d/net for anything else. When the postup() function is entered, the IFACE variable is automatically set to the name of the interface that triggered the event. Anything that is valid bash can go there. Cool. That's the main piece I hadn't figured out yet. Thanks! -- Grant Edwards grant.b.edwardsYow! Now KEN and BARBIE at are PERMANENTLY ADDICTED to gmail.comMIND-ALTERING DRUGS ...
[gentoo-user] Re: Mantle Open source GPU engine
Bruce Hill daddy at happypenguincomputers.com writes: computer gaming (yawn)... think database acceleration, load of additional mathematically tuned addtional hardware for both MIPS/MOPS etc etc think: an order of magnitue more hardware campacity of the workstation or server, now fully utilizing the GPU(s). Think searching and sorting algorithms running at orders of magnitude fasters. Now use these in networked distributed and clustered systems. Think of the hardware assault on a range of NP Complete problems that only a few larges systems can tackle today. Think man think of all of the projects, where NDA's are signed and software vendors customize solutions for DOD, Aerospace and other massive problems, all solved with the use of bare metal and lightweight alogrithms that run on bare metal It will eventually effect everything that is done computationally, not just limited to graphical interfaces. The problem is we have been lead down this path before, via marketing hype, and denieded bare metal access. Bare metal access for lightweight or custom algorithms, have traditionally been extraordinarily expense to gain access to. Typically, hardware vendors select only a few outside companies to really have access to these things. Every layer of the API, system calls, IPC, etc, involves using scarce hardware resources to manage for an OS. Bare metal access, particularly if something like GCC incorporates this bare metal access, via a compiler, it allows GPUs to be use as reconfigurable blocks for custom and continuouse searching and sorting. Searching and sorting the the most important things in a multi-user multi-thread operating system, imho. These secrets are worth billions to these vendors (Nvidia, AMD ) and as such have been locked away from routine computational use. If access is truly opened up, a war for tight integration amoung all hardware vendors will transpire (FPGA, ASIC, GPU, CPU and memory). It is a GAME CHANGER, IFF true, that is ifunadulterated bare metal access is being provided to the masses Otherwise, your yawn rules the day. and this just may turn out to be more hype, as it is limited to NDAs between game developers and the hardware vendor, in yet another exclusive club. hth, James
[gentoo-user] Re: Mantle Open source GPU engine
James wireless at tampabay.rr.com writes: computer gaming (yawn)... The Kalman filter operates recursively on streams of noisy input data to produce a statistically optimal estimate of the underlying system state. [1] (sounds like a database admin's dream tool, huh?) clean usage from dirty/corrupted data (think NSA, DOD etc etc). You like video on the Net? The Kalman Filter is one of the chief mathmatical advances in the field of video and graphics, among a myriad of other applications. The Kalman filter is unknown to most digital mathmaticians and application programers, but these days they rarely perform seraching or sorting without the benefits of Kalman Filters running on hardware (bare metal).. The Kalman Filter is but one of the bare metal Algorithms that will benefit by orders of magnitude with true bare metal access to the GPU. [2] If you really want to learn about where hardware meets software, read up on this man : Donald Knuth. Most programmers has never heard of him, let alone comprehend his body of work. hth, James [1] http://en.wikipedia.org/wiki/Kalman_filter [2] http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=6121397url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6121397
Re: [gentoo-user] Re: Mantle Open source GPU engine
On Fri, Oct 04, 2013 at 04:49:24PM +, James wrote: James wireless at tampabay.rr.com writes: computer gaming (yawn)... The Kalman filter operates recursively on streams of noisy input data to produce a statistically optimal estimate of the underlying system state. [1] (sounds like a database admin's dream tool, huh?) clean usage from dirty/corrupted data (think NSA, DOD etc etc). You like video on the Net? The Kalman Filter is one of the chief mathmatical advances in the field of video and graphics, among a myriad of other applications. The Kalman filter is unknown to most digital mathmaticians and application programers, but these days they rarely perform seraching or sorting without the benefits of Kalman Filters running on hardware (bare metal).. The Kalman Filter is but one of the bare metal Algorithms that will benefit by orders of magnitude with true bare metal access to the GPU. [2] If you really want to learn about where hardware meets software, read up on this man : Donald Knuth. Most programmers has never heard of him, let alone comprehend his body of work. hth, James [1] http://en.wikipedia.org/wiki/Kalman_filter [2] http://ieeexplore.ieee.org/xpl/login.jsp?tp=arnumber=6121397url=http%3A%2F%2Fieeexplore.ieee.org%2Fxpls%2Fabs_all.jsp%3Farnumber%3D6121397 Hi James, Sorry for such a terse, if not rude, response. You did, however, get the meaning and respond accordingly. ;) I'm familiar with Donald Knuth The Art of Computer Programming, TeX, etc. And now that you've delved into some of the better reasons, I'm all ears. Still, I would have highly chastised someone calling me about this in the middle of the night. Even if it were one of my friends 13 time zones away. ;) Cheers, Bruce -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
Re: [gentoo-user] Mantle Open source GPU engine
On 04/10/2013 18:04, Bruce Hill wrote: If this is true, it is a GAME CHANGERS (could not resist the pun). So: A. it is time for me to dig into this issue. B. Are any of the folks on this list working to get Mantle support available on Gentoo? C. Anyone tested one of the Hawaii radeon cards? D. Anyone working on running SteamOS virtualize on (gentoo) linux? as always, your thoughts are most welcome James [1] http://www.pcworld.com/article/2049369/amd-nvidia-ramp-up-linux-driver-support-after-valves-steamos-announcement.html [2] http://www.tomshardware.com/news/amd-mantle-api-gcn-battlefield-4,24418.html computer gaming (yawn)... Think again. What is the driving force behind all the super-duper performance hardware you have right now? Gaming. What is the GPU capable of achieving when parallelized? Well, graphics rendering is highly parallelizable and nowadays you see it in render farms and Top500 supercomputers. But those didn;t fund it, so what did? Graphics cards sold to gamers. Graphics cards for gamers are probably the only thing left really keeping the pc market as such going. Yes, there are still millions of them on corporate desktops but that is a cut-throat market and at what-tiny-number-of-bucks a pop? Bread and butter money, it keeps things ticking over and pays the rent. But gamers pay for the bling. Almost ever awesome performance gain in the last 10 years at least that you see in commercial products were driven in whole or in part by the primary high performance market - gamers. Personally, I don't like games much and don't play them much. OK, I don't play them at all. But the market they make up - that's different. Those egg-heads are very important -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Network failed and weird error message
On 04/10/2013 18:09, Dale wrote: Sometime last night while I was sleeping, my network sort of hiccuped. If I went to a Konsole, I could ping google so it appears the network was working on the lower level but not one browser that was left open would work. It also didn't/couldn't download new emails. When I restarted the browser, it worked. This is the case for both Seaminkey and Firefox. If it was just one, I'd think browser issue but not two of them at the same time. This is a example of what is in my messages file: Sep 29 03:10:15 localhost kernel: [382175.585718] ohci_hcd :00:12.1: urb 88034092b0c0 path 1 ep1in 9312 cc 9 -- status -121 Sep 29 03:10:17 localhost kernel: [382177.582033] ohci_hcd :00:12.1: urb 8803f06a9d40 path 1 ep1in 9212 cc 9 -- status -121 Sep 29 03:10:19 localhost kernel: [382179.586285] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9312 cc 9 -- status -121 Sep 29 03:10:21 localhost kernel: [382181.582602] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9212 cc 9 -- status -121 Sep 29 03:10:23 localhost kernel: [382183.586879] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9312 cc 9 -- status -121 What I read from your description is that Seamonkey and Firefox hiccuped and everything else either works or was not tested. Assuming that those browsers share lots of common code - see where I'm going with this? The entries in your messages file may or may not be relevant, and if they are relevant it will be as a side effect. OHCI is a USB 1.1 implementation, I can't imagine why you have it loaded. Surely you do not have USB 1 only hardware? USB2 deals with that nicely. It is possible that you have a shit storm of USB weirdness going on and this in locking up the desktop. Try disabling USB stuff you don't need and see what gives. I did a google search but obviously not direct hits so I had to adjust things until I got some hits. I removed for example the time stamp and lots of other unigue things to my system. The closest hit I got was three years ago and it's not the same even allowing for the stuff that will change. So, google was no help. I did a update last night. It updated the kernel sources but I haven't touched it yet. It updated the virtual for udev and nvidia-drivers which I am using at the moment. The only one I see that could possibly affect this is the udev one but I don't think it is likely since it is a virtual and the actual dev package didn't change. By the way, I use checkrestart after updates. If needed, I go to boot runlevel and restart whatever else is needed to get a clean output. I did rmmod nvidia and modprobe nvidia last night. I'm hoping this driver will not cause my kicker thingy to lock up like the last dozen or so has. :/ Keep in mind, the network worked in a Konsole. It appears to me it was KDE and/or things running inside of KDE and a regular user that had issues. I only checked my Seamonkey and Firefox and they did not work until they was restarted. My grand fix was to log out and log back in again. I just checked again, I am still getting the errors above even tho the browsers are working. The error above may not be related to this. Sort of confusing at the moment. Kernel problem? KDE problem? Some USB error? Something else? Thoughts? Dale :-) :-) P. S. This is what I get while restarting my network service: Oct 4 10:27:13 localhost kernel: [839575.429674] ohci_hcd :00:12.1: urb 8802f06dc240 path 1 ep1in 9312 cc 9 -- status -121 Oct 4 10:27:15 localhost kernel: [839577.425964] ohci_hcd :00:12.1: urb 8802f06dc240 path 1 ep1in 9212 cc 9 -- status -121 Oct 4 10:27:17 localhost kernel: [839579.430267] ohci_hcd :00:12.1: urb 8802f06dc6c0 path 1 ep1in 9312 cc 9 -- status -121 Oct 4 10:27:17 localhost sshd[8316]: Received signal 15; terminating. Oct 4 10:27:17 localhost kernel: [839580.289194] r8169 :03:00.0 eth0: link down Oct 4 10:27:17 localhost kernel: [839580.289204] r8169 :03:00.0 eth0: link down Oct 4 10:27:17 localhost kernel: [839580.289256] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready Oct 4 10:27:18 localhost sshd[8692]: Server listening on 0.0.0.0 port 22. Oct 4 10:27:18 localhost sshd[8692]: Server listening on :: port 22. Oct 4 10:27:19 localhost kernel: [839581.426532] ohci_hcd :00:12.1: urb 88042086ac00 path 1 ep1in 9212 cc 9 -- status -121 Oct 4 10:27:19 localhost kernel: [839582.327590] r8169 :03:00.0 eth0: link up Oct 4 10:27:19 localhost kernel: [839582.327599] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready Oct 4 10:27:21 localhost kernel: [839583.430811] ohci_hcd :00:12.1: urb 8802f06dc6c0 path 1 ep1in 9312 cc 9 -- status -121 Oct 4 10:27:22 localhost kernel: [839584.527264] r8169 :03:00.0 eth0: link down Oct 4 10:27:23 localhost kernel:
Re: [gentoo-user] Multiple package instances within a single package slot
On 04/10/2013 17:40, Alex Schuster wrote: Well. Sort of. Emerge also wanted to re-merge libreoffice, I have no idea why. The same happened yesterday when I upgraded portage. Whatever :) This time, I used --exclude app-office/libreoffice to avoid this. probably a poppler or icu or java update, or any one of the many things libreoffice uses that changes ABI at the drop of a hat. Recent portage with subslot support triggers a libreoffice rebuild when that happens, it is seldom an error. You can leave it out of the world emerge to speed things up, but revdep-rebuild is probably going to also find it and want to do the same -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Network failed and weird error message
Alan McKinnon wrote: On 04/10/2013 18:09, Dale wrote: Sometime last night while I was sleeping, my network sort of hiccuped. If I went to a Konsole, I could ping google so it appears the network was working on the lower level but not one browser that was left open would work. It also didn't/couldn't download new emails. When I restarted the browser, it worked. This is the case for both Seaminkey and Firefox. If it was just one, I'd think browser issue but not two of them at the same time. This is a example of what is in my messages file: Sep 29 03:10:15 localhost kernel: [382175.585718] ohci_hcd :00:12.1: urb 88034092b0c0 path 1 ep1in 9312 cc 9 -- status -121 Sep 29 03:10:17 localhost kernel: [382177.582033] ohci_hcd :00:12.1: urb 8803f06a9d40 path 1 ep1in 9212 cc 9 -- status -121 Sep 29 03:10:19 localhost kernel: [382179.586285] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9312 cc 9 -- status -121 Sep 29 03:10:21 localhost kernel: [382181.582602] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9212 cc 9 -- status -121 Sep 29 03:10:23 localhost kernel: [382183.586879] ohci_hcd :00:12.1: urb 8803f06a9680 path 1 ep1in 9312 cc 9 -- status -121 What I read from your description is that Seamonkey and Firefox hiccuped and everything else either works or was not tested. Assuming that those browsers share lots of common code - see where I'm going with this? The entries in your messages file may or may not be relevant, and if they are relevant it will be as a side effect. OHCI is a USB 1.1 implementation, I can't imagine why you have it loaded. Surely you do not have USB 1 only hardware? USB2 deals with that nicely. It is possible that you have a shit storm of USB weirdness going on and this in locking up the desktop. Try disabling USB stuff you don't need and see what gives. I do see where you are going with this and is sort of my thinking too. It seems tho, pidgin wasn't working either. I always have pidgin as online by default but was bumped off during this weird thing going on. Still confusing huh? Oh, my Konsole is run as root. When I copied the first error message, I had my cell phone plugged in to charge it up. My phone charges better off the puter than it does from the charger plugged into the wall. Yes, I even bought a new charger. It charges but takes MUCH longer than when plugged into my puter. Anyway. Nothing else plugged in, no printer, no scanner either. Well, just thought of this. My UPS is now USB. I can't unplug that. The second post below the P. S. part, that was with the cell phone unplugged. I been online today and somewhat active. No problem so far. Not finding anything on google tho, that has me puzzled. I just checked, I am still getting that error in messages file. I may have to redo my kernel, reboot and test some more. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Mantle Open source GPU engine
On Fri, Oct 04, 2013 at 09:20:43PM +0200, Alan McKinnon wrote: computer gaming (yawn)... Think again. What is the driving force behind all the super-duper performance hardware you have right now? Gaming. What is the GPU capable of achieving when parallelized? Well, graphics rendering is highly parallelizable and nowadays you see it in render farms and Top500 supercomputers. But those didn;t fund it, so what did? Graphics cards sold to gamers. Graphics cards for gamers are probably the only thing left really keeping the pc market as such going. Yes, there are still millions of them on corporate desktops but that is a cut-throat market and at what-tiny-number-of-bucks a pop? Bread and butter money, it keeps things ticking over and pays the rent. But gamers pay for the bling. Almost ever awesome performance gain in the last 10 years at least that you see in commercial products were driven in whole or in part by the primary high performance market - gamers. Personally, I don't like games much and don't play them much. OK, I don't play them at all. But the market they make up - that's different. Those egg-heads are very important See previous reply in thread to James. This one was not threaded, but rather, a reply to the OP, so it makes it look as if you haven't read the thread. I played one computer game one day in 1990. Lost that entire day to that stupid game, and never played again. Except...one time for a few hours with a new friend the second year living in China. He wanted me to play NFS. After playing a few races with him, I explained that we do this with _real_cars_ on _real_roads_ in _real_life_ back in America. It developed from the days of moonshining, and your car (and you as a driver) weren't anything if you couldn't outrun the local cops. ;) My gaming yawn was a poor, and needless, expression of disgust. -- Happy Penguin Computers ') 126 Fenco Drive ( \ Tupelo, MS 38801 ^^ supp...@happypenguincomputers.com 662-269-2706 662-205-6424 http://happypenguincomputers.com/ A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Don't top-post: http://en.wikipedia.org/wiki/Top_post#Top-posting
[gentoo-user] OT: default route dependent on dest port?
Let's posit two network interfaces net1 (192.168.x.y/16) and net2 (172.16.a.b/16). There's a NAT/gateway available on each of the networks. I want to use the 172.16 gateway for TCP connections to port 80 and the 192.168 gateway for everything else. I'm primarily following this example: http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html My main routing table contains all directly accessible subnets plus a default route via the 192.168 gateway. I created a second route table named pmain which is identical to main except it has a different default route via the 172.16 gateway. My ip rules are: 0: from all lookup local 1: from all fwmark 0x1 lookup pmain 32766: from all lookup main 32767: from all lookup default I then add an iptables rule like this: iptables -A OUTPUT -t mangle -p tcp --dport 80 -j MARK --set-mark 1 Now all TCP packets destined for port 80 are sent to the 172.16 gateway, _but_ they're being sent with a 192.168 source address. The TCP stack is apparently unaware of the advanced routing tricks and thinks that the packets are going out via the 192.168 gateway. IOW I've succesfully re-routed TCP _packets_ but not the TCP _connection_. How do I tell the TCP stack that it's supposed to use the 172.16 inteface/gateway for connections to port 80? -- Grant Edwards grant.b.edwardsYow! I feel partially at hydrogenated! gmail.com
Re: [gentoo-user] OT: default route dependent on dest port?
On 04/10/2013 21:55, Grant Edwards wrote: Let's posit two network interfaces net1 (192.168.x.y/16) and net2 (172.16.a.b/16). There's a NAT/gateway available on each of the networks. I want to use the 172.16 gateway for TCP connections to port 80 and the 192.168 gateway for everything else. I'm primarily following this example: http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html My main routing table contains all directly accessible subnets plus a default route via the 192.168 gateway. I created a second route table named pmain which is identical to main except it has a different default route via the 172.16 gateway. My ip rules are: 0: from all lookup local 1: from all fwmark 0x1 lookup pmain 32766: from all lookup main 32767: from all lookup default I then add an iptables rule like this: iptables -A OUTPUT -t mangle -p tcp --dport 80 -j MARK --set-mark 1 It would help if you were to also supply the details of: * ip -f inet -o a s * ip route show table main * ip route show table pmain Now all TCP packets destined for port 80 are sent to the 172.16 gateway, _but_ they're being sent with a 192.168 source address. The TCP stack is apparently unaware of the advanced routing tricks and thinks that the packets are going out via the 192.168 gateway. IOW I've succesfully re-routed TCP _packets_ but not the TCP _connection_. How do I tell the TCP stack that it's supposed to use the 172.16 inteface/gateway for connections to port 80? --Kerin
Re: [gentoo-user] Network failed and weird error message
On Fri, Oct 04, 2013 at 09:35:33PM +0200, Alan McKinnon wrote OHCI is a USB 1.1 implementation, I can't imagine why you have it loaded. Surely you do not have USB 1 only hardware? USB2 deals with that nicely. It is possible that you have a shit storm of USB weirdness going on and this in locking up the desktop. Try disabling USB stuff you don't need and see what gives. Do *NOT* remove lowspeed USB driver... unless you have a rescue USB stick boot handy. I tried that a few years ago and found that my USB keyboard and mouse stopped working. UHCI is used by Intel and VIA cpus, according to the help in make menuconfig. AMD may be OHCI, I don't know. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Where to put advanced routing configuration?
On 10/03/2013 04:28 PM, Kerin Millar wrote: The iptables runscript is ideal for persisting the rules. However, during the initial construction of a non-trivial ruleset, I prefer to write a script that adds the rules. An elegant way of doing this is to use iptables-restore with a heredoc. The method - and its advantages - are described in this document (section 3): http://inai.de/documents/Perfect_Ruleset.pdf This advice is dubious in my opinion. The `iptables` command line is the published interface to iptables. The iptables-restore syntax is an implementation detail, subject to change at any time. Here are his arguments: 1. Calling iptables repeatedly is slow. Who cares? How often do you invoke the script? Once or twice a year when you change it. 2. There is an opportunity for someone to bypass the rules between dropping/recreating them. Again, you run the script once or twice a year. Turn off the interface beforehand if a few microseconds per year is too long to run without a firewall. And my counterarguments: 1. The iptables-restore syntax is uglier and harder to read. 2. You get better error reporting calling iptables repeatedly. 3. The published interface will never change; iptables-restore reads an input language whose specification is whatever iptables-save outputs. 4. A bash script is far more standard and less confusing to your coworkers. 5. You can't script iptables-restore! What if you want to call sed, cut, or grep on something and pass that to iptables? You can write a bash script that writes an iptables-restore script to accomplish the same thing, but how much complexity are you willing to add for next to no benefit?
Re: [gentoo-user] OT: default route dependent on dest port?
On Fri, 4 Oct 2013 20:55:25 + (UTC) Grant Edwards grant.b.edwa...@gmail.com wrote: Let's posit two network interfaces net1 (192.168.x.y/16) and net2 (172.16.a.b/16). There's a NAT/gateway available on each of the networks. I want to use the 172.16 gateway for TCP connections to port 80 and the 192.168 gateway for everything else. I'm primarily following this example: http://www.tldp.org/HOWTO/Adv-Routing-HOWTO/lartc.netfilter.html My main routing table contains all directly accessible subnets plus a default route via the 192.168 gateway. I created a second route table named pmain which is identical to main except it has a different default route via the 172.16 gateway. My ip rules are: 0: from all lookup local 1: from all fwmark 0x1 lookup pmain 32766: from all lookup main 32767: from all lookup default I then add an iptables rule like this: iptables -A OUTPUT -t mangle -p tcp --dport 80 -j MARK --set-mark 1 Now all TCP packets destined for port 80 are sent to the 172.16 gateway, _but_ they're being sent with a 192.168 source address. The TCP stack is apparently unaware of the advanced routing tricks and thinks that the packets are going out via the 192.168 gateway. IOW I've succesfully re-routed TCP _packets_ but not the TCP _connection_. How do I tell the TCP stack that it's supposed to use the 172.16 inteface/gateway for connections to port 80? Hi, It's been a while but i believe you want to route via interface not gateway. Providing more info will make it easier to help you.
[gentoo-user] Re: OT: default route dependent on dest port?
On 2013-10-04, Kerin Millar kerfra...@fastmail.co.uk wrote: On 04/10/2013 21:55, Grant Edwards wrote: I then add an iptables rule like this: iptables -A OUTPUT -t mangle -p tcp --dport 80 -j MARK --set-mark 1 I'm about to try adding a second iptables rule to us the nat table to rewrite the source IP address. Something like this: iptables -A POSTROUTING -t nat -o net2 -m mark --mark 1 -j SNAT --to 172.16.1.2 It would help if you were to also supply the details of: * ip -f inet -o a s $ ip -f inet -o a s 1: loinet 127.0.0.1/8 scope host lo 2: net0inet 192.168.8.4/16 brd 192.168.255.255 scope global net0 3: net1inet 10.0.0.1/8 brd 10.255.255.255 scope global net1 3: net1inet 192.168.250.1/24 brd 192.168.250.255 scope global net1 3: net1inet 192.168.1.1/24 brd 192.168.1.255 scope global net1 3: net1inet 169.254.1.1/16 brd 169.254.255.255 scope global net1 5: net2inet 172.16.1.2/16 brd 172.16.255.255 scope global net2 * ip route show table main $ ip route show table main default via 192.168.0.254 dev net0 metric 2 10.0.0.0/8 dev net1 proto kernel scope link src 10.0.0.1 127.0.0.0/8 via 127.0.0.1 dev lo 169.254.0.0/16 dev net1 proto kernel scope link src 169.254.1.1 172.16.0.0/16 dev net2 proto kernel scope link src 172.16.1.2 metric 5 192.168.0.0/16 dev net0 proto kernel scope link src 192.168.8.4 192.168.1.0/24 dev net1 proto kernel scope link src 192.168.1.1 192.168.250.0/24 dev net1 proto kernel scope link src 192.168.250.1 * ip route show table pmain $ ip route show table pmain default via 172.16.0.34 dev net2 metric 2 10.0.0.0/8 dev net1 proto kernel scope link src 10.0.0.1 127.0.0.0/8 via 127.0.0.1 dev lo 169.254.0.0/16 dev net1 proto kernel scope link src 169.254.1.1 172.16.0.0/16 dev net2 proto kernel scope link src 172.16.1.2 metric 5 192.168.0.0/16 dev net0 proto kernel scope link src 192.168.8.4 192.168.1.0/24 dev net1 proto kernel scope link src 192.168.1.1 192.168.250.0/24 dev net1 proto kernel scope link src 192.168.250.1 Now all TCP packets destined for port 80 are sent to the 172.16 gateway, _but_ they're being sent with a 192.168 source address. The TCP stack is apparently unaware of the advanced routing tricks and thinks that the packets are going out via the 192.168 gateway. IOW I've succesfully re-routed TCP _packets_ but not the TCP _connection_. How do I tell the TCP stack that it's supposed to use the 172.16 inteface/gateway for connections to port 80? --Kerin -- Grant Edwards grant.b.edwardsYow! ! I'm in a very at clever and adorable INSANE gmail.comASYLUM!!
Re: [gentoo-user] Where to put advanced routing configuration?
On Fri, 04 Oct 2013 17:58:14 -0400 Michael Orlitzky mich...@orlitzky.com wrote: On 10/03/2013 04:28 PM, Kerin Millar wrote: The iptables runscript is ideal for persisting the rules. However, during the initial construction of a non-trivial ruleset, I prefer to write a script that adds the rules. An elegant way of doing this is to use iptables-restore with a heredoc. The method - and its advantages - are described in this document (section 3): http://inai.de/documents/Perfect_Ruleset.pdf This advice is dubious in my opinion. The `iptables` command line is the published interface to iptables. The iptables-restore syntax is an implementation detail, subject to change at any time. Here are his arguments: 1. Calling iptables repeatedly is slow. Who cares? How often do you invoke the script? Once or twice a year when you change it. 2. There is an opportunity for someone to bypass the rules between dropping/recreating them. Again, you run the script once or twice a year. Turn off the interface beforehand if a few microseconds per year is too long to run without a firewall. And my counterarguments: 1. The iptables-restore syntax is uglier and harder to read. 2. You get better error reporting calling iptables repeatedly. 3. The published interface will never change; iptables-restore reads an input language whose specification is whatever iptables-save outputs. 4. A bash script is far more standard and less confusing to your coworkers. 5. You can't script iptables-restore! What if you want to call sed, cut, or grep on something and pass that to iptables? You can write a bash script that writes an iptables-restore script to accomplish the same thing, but how much complexity are you willing to add for next to no benefit? Hi, Many people use netfilter for busy firewalls not just for set and forget firewalls. Having hundreds or thousands of rules and IPs makes managing netfilter with iptables problematic. That is when it's advisable to change the filter in one swoop with restore or ipset. Bottom line is your individual use case is just that, individual.
[gentoo-user] Re: OT: default route dependent on dest port?
On 2013-10-04, Dragostin Yanev gentoo+u...@netixen.com wrote: On Fri, 4 Oct 2013 20:55:25 + (UTC) IOW I've succesfully re-routed TCP _packets_ but not the TCP _connection_. How do I tell the TCP stack that it's supposed to use the 172.16 inteface/gateway for connections to port 80? It's been a while but i believe you want to route via interface not gateway. Providing more info will make it easier to help you. Can you explain what route via interface means? I tried a default route like this: ip route add table pmain default dev net2 instead of: ip route add table pmain default via gateway-ip dev net2 But then non-local packets routed via that table don't seem to go out any interface at all. -- Grant Edwards grant.b.edwardsYow! I'm meditating on at the FORMALDEHYDE and the gmail.comASBESTOS leaking into my PERSONAL SPACE!!
[gentoo-user] Re: OT: default route dependent on dest port?
On 2013-10-04, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2013-10-04, Kerin Millar kerfra...@fastmail.co.uk wrote: On 04/10/2013 21:55, Grant Edwards wrote: I then add an iptables rule like this: iptables -A OUTPUT -t mangle -p tcp --dport 80 -j MARK --set-mark 1 I'm about to try adding a second iptables rule to us the nat table to rewrite the source IP address. Something like this: iptables -A POSTROUTING -t nat -o net2 -m mark --mark 1 -j SNAT --to 172.16.1.2 I also tried iptables -A POSTROUTING -t nat -o net2 -p tcp --dport 80 -j SNAT --to 172.16.1.2 [I don't think the second rule is quite right, though, since it will also match packets that _don't_ need to have the source IP re-written.] Both produced the same results: outbound packets look correct (they have a source address that's valid for the net2 interface). But, inbound packets don't seem to reach the TCP stack: SYN goes out SYN/ACK comes back SYN gets resent SYN/ACK comes back SYN gets resent SYN/ACK comes back The src/dst addresses in both the outbound SYN and the inbound SYN/ACK look right. Do I need another iptables rule to rewrite the destination IP on the inbound packets? -- Grant Edwards grant.b.edwardsYow! Does someone from at PEORIA have a SHORTER gmail.comATTENTION span than me?
[gentoo-user] Re: OT: default route dependent on dest port?
On 2013-10-04, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2013-10-04, Grant Edwards grant.b.edwa...@gmail.com wrote: On 2013-10-04, Kerin Millar kerfra...@fastmail.co.uk wrote: On 04/10/2013 21:55, Grant Edwards wrote: I then add an iptables rule like this: iptables -A OUTPUT -t mangle -p tcp --dport 80 -j MARK --set-mark 1 I'm about to try adding a second iptables rule to us the nat table to rewrite the source IP address. Something like this: iptables -A POSTROUTING -t nat -o net2 -m mark --mark 1 -j SNAT --to 172.16.1.2 I also tried iptables -A POSTROUTING -t nat -o net2 -p tcp --dport 80 -j SNAT --to 172.16.1.2 [I don't think the second rule is quite right, though, since it will also match packets that _don't_ need to have the source IP re-written.] Both produced the same results: outbound packets look correct (they have a source address that's valid for the net2 interface). But, inbound packets don't seem to reach the TCP stack: If I disable reverse-path filtering then it works. [I'm using the first SNAT rule that matches based on the mark], but I don't really like disabling all the reverse path filtering. Is there a cleaner way to accomplish this that doesn't fall afoul of rp_filter? -- Grant Edwards grant.b.edwardsYow! I have accepted at Provolone into my life! gmail.com
