Re: [gentoo-user] How to prevent a dns amplification attack
On 31-Mar-13 4:08, Paul Hartman wrote: Coincidentally, yesterday US-CERT published a small article about DNS amplification attacks and mitigation strategies: http://www.us-cert.gov/ncas/alerts/TA13-088A Thanks for interesting link. I did not know bind has support for response rate-limiting... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
[gentoo-user] Re: Udev update and persistent net rules changes
On 30/03/13 17:15, Tanstaafl wrote: Ok, just read the new news item and the linked udev-guide wiki page You should probably also read: http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names and: http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Nikos Chantziaras rea...@gmail.com wrote: On 30/03/13 17:15, Tanstaafl wrote: Ok, just read the new news item and the linked udev-guide wiki page You should probably also read: http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names and: http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names The feeling that I got while reading the first was exactly what the second talks about. We - from what I understand - had scripts automatically generating the name rules from MAC addresses, it's just that they generated stuff like ethX. Can't we just keep these scripts around (even if this was something provided by upstream and we would have to forge a new incarnation)? I mean, IMHO, net0, wl0, ... are much easier to deal with and understand than something physically-based. They also avoid problems caused by moving these cards around, or changes in the kernel drivers or BIOS, or BIOS settings that eventually end up exposing cards in a different way. The problem with the old approach was *just* the name clash that rendered the hacky approach unreliable. Maybe we could just fix the issue by using non-clashing namespaces, instead of pushing a completely different (and possibly less reliable) naming scheme by default. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Difference between --update and --emptytree?
Am 31.03.2013 05:12, schrieb Walter Dnes: On Sat, Mar 30, 2013 at 10:04:24PM -0400, Mike Gilbert wrote On Sat, Mar 30, 2013 at 9:49 PM, Walter Dnes waltd...@waltdnes.org wrote: Did an update today. After the update, I checked again... [d531][waltdnes][~] emerge -pv --update --changed-use world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB Good... nothing to add... I think. But replace --update with --emptytree, and a whole bunch of new and updated stuff shows up. Is there a logical explanation? Should I emerge world? Or just the new and updated stuff (with the -1 flag)? Here are listings of the new and updated stuff... The extra stuff is probably build-time deps, which do not get updated by default. Try this: emerge -pv --update --changed-use --with-bdeps=y world I see nothing at all to be emerged... [d531][waltdnes][~] emerge -pv --update --changed-use --with-bdeps=y world These are the packages that would be merged, in order: Calculating dependencies... done! Total: 0 packages, Size of downloads: 0 kB You can also try adding --deep to your emerge options. Or double check with eix -u -c I've written an autodepclean script that I run to guide me through cleaning up orphaned dependancies. Think of it as a sane depclean. After each use, I run revdep-rebuild to ensure that nothing is broken. Could this be at the root of my situation? What do you mean by sane depclean? Are there any problems with --depclean that I am not aware of?
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: On 2013-03-31, Nikos Chantziaras rea...@gmail.com wrote: On 30/03/13 17:15, Tanstaafl wrote: Ok, just read the new news item and the linked udev-guide wiki page You should probably also read: http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names and: http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names The feeling that I got while reading the first was exactly what the second talks about. We - from what I understand - had scripts automatically generating the name rules from MAC addresses, it's just that they generated stuff like ethX. Can't we just keep these scripts around (even if this was something provided by upstream and we would have to forge a new incarnation)? I mean, IMHO, net0, wl0, ... are much easier to deal with and understand than something physically-based. They also avoid problems caused by moving these cards around, or changes in the kernel drivers or BIOS, or BIOS settings that eventually end up exposing cards in a different way. The problem with the old approach was *just* the name clash that rendered the hacky approach unreliable. Maybe we could just fix the issue by using non-clashing namespaces, instead of pushing a completely different (and possibly less reliable) naming scheme by default. Ok, after some chat on IRC, it seems that upstream made it rather non-trivial to have something like the old rule-generator, and that's why we can't simply move that from, e.g., ethX to, say, netX. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Difference between --update and --emptytree?
On Sun, Mar 31, 2013 at 01:56:25PM +0200, Michael Hampicke wrote You can also try adding --deep to your emerge options. That seems to be it... emerge -pv --update --changed-use --deep --with-bdeps=y world produces a list of packages. The list ends with... Total: 52 packages (29 upgrades, 23 new), Size of downloads: 6,521 kB Conflict: 1 block The 29 upgrades and 23 new seem to exactly match what I had from the new and upgrade portions of emerge world. Thanks for your help. What do you mean by sane depclean? Are there any problems with --depclean that I am not aware of? emerge -p --depclean generates dire warnings. I keep a previous version of the kernel (gentoo-sources) as a fallback, and --depclean wants to remove that, which I want to keep. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Difference between --update and --emptytree?
On Sunday 31 March 2013 14:09:56 Walter Dnes wrote: I keep a previous version of the kernel (gentoo-sources) as a fallback, and --depclean wants to remove that, which I want to keep. if you let it unmerge the old kernel it will only remove the sources. Everything that's generated by building the kernel will be left alone. Would that suit you? It's what I do here, anyway: -- Peter
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Mar 31, 2013 7:13 PM, Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: On 2013-03-31, Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: On 2013-03-31, Nikos Chantziaras rea...@gmail.com wrote: On 30/03/13 17:15, Tanstaafl wrote: Ok, just read the new news item and the linked udev-guide wiki page You should probably also read: http://blog.flameeyes.eu/2013/03/predictably-non-persistent-names and: http://blog.flameeyes.eu/2013/03/predictable-persistently-non-mnemonic-names The feeling that I got while reading the first was exactly what the second talks about. We - from what I understand - had scripts automatically generating the name rules from MAC addresses, it's just that they generated stuff like ethX. Can't we just keep these scripts around (even if this was something provided by upstream and we would have to forge a new incarnation)? I mean, IMHO, net0, wl0, ... are much easier to deal with and understand than something physically-based. They also avoid problems caused by moving these cards around, or changes in the kernel drivers or BIOS, or BIOS settings that eventually end up exposing cards in a different way. The problem with the old approach was *just* the name clash that rendered the hacky approach unreliable. Maybe we could just fix the issue by using non-clashing namespaces, instead of pushing a completely different (and possibly less reliable) naming scheme by default. Ok, after some chat on IRC, it seems that upstream made it rather non-trivial to have something like the old rule-generator, and that's why we can't simply move that from, e.g., ethX to, say, netX. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/ Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... Rgds, --
[gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
Googled and can't seem to find an answer to this... I've had FEATURES=buildpkg for some time on my system, so I already have udev-171-r10 quickpkg'd... But for the life of me, I can't seem to find instructions for how to convert /usr/portage/packages/sys-fs/udev-171-r10.tbz2 to an ebuild that I can then add to my local overlay... Can this be done with the quickpkg command, or some other portage tool/command? Or do I have to Anyone know how to do this? I'm basically using this udev event to learn a little about how quickpkg works, so, since udev-171 is no longer in the portage tree, I want to convert my quickpkg of it to an ebuild in my local overlay so my mask will work again... then I'll back everything up, and do the update to udev...
Re: eudev - is it a viable *long-term* option? - WAS: Re: [gentoo-user] Updating our live servers. I'm scared!
On 2013-03-30 1:41 PM, Pandu Poluan pa...@poluan.info wrote: All my servers use mdev. 'nuff said. I do remember the conversation about mdev... probably should have paid closer attention. Is the conversion fairly simple? Is there an updated how-to, specifically for older udev (171)? Thanks...
Re: [gentoo-user] udev-197 vs udev-200??
On 2013-03-30 1:22 PM, Mark David Dumlao madum...@gmail.com wrote: On 03/30/2013 11:24 PM, Tanstaafl wrote: Ok, I don't understand this... snip emerge -pvuDN world shows updates to BOTH virtual/udev-197-r2 *and* udev-200, with strange Blockers referencing udev-186??? My reading is: there are some packages either in your tree or being pulled in that require a later version of udev. So even if you mask udev-197, it's still being pulled in by something else. Thanks, but actually, I had just forgotten that 171-r10 is no longer in portage. So, now I'm trying to figure out how to convert my quickpkg of it to an ebuild I can add to my local overlay...
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... Rgds, -- I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: eudev - is it a viable *long-term* option? - WAS: Re: [gentoo-user] Updating our live servers. I'm scared!
Tanstaafl wrote: On 2013-03-30 1:41 PM, Pandu Poluan pa...@poluan.info wrote: All my servers use mdev. 'nuff said. I do remember the conversation about mdev... probably should have paid closer attention. Is the conversion fairly simple? Is there an updated how-to, specifically for older udev (171)? Thanks... Try this: https://wiki.gentoo.org/wiki/Mdev That was originally done by Walter and he does subscribe to this list, saw a post not to long ago. If you run into issues, I'm pretty sure he will help if he can. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 31/03/13 at 12:41pm, Tanstaafl wrote: Googled and can't seem to find an answer to this... I've had FEATURES=buildpkg for some time on my system, so I already have udev-171-r10 quickpkg'd... But for the life of me, I can't seem to find instructions for how to convert /usr/portage/packages/sys-fs/udev-171-r10.tbz2 to an ebuild that I can then add to my local overlay... Can this be done with the quickpkg command, or some other portage tool/command? Or do I have to Anyone know how to do this? I'm basically using this udev event to learn a little about how quickpkg works, so, since udev-171 is no longer in the portage tree, I want to convert my quickpkg of it to an ebuild in my local overlay so my mask will work again... then I'll back everything up, and do the update to udev... Although that is sort of possible that's not how your supposed to use binary packages with portage. What you need to do is add the original ebuild for udev-171 to your local overlay as is. Then run emerge using the -g option see man emerge. For more info on bin packages see http://wiki.gentoo.org/wiki/Binary_package_guide -- - Yohan Pereira The difference between a Miracle and a Fact is exactly the difference between a mermaid and a seal. -- Mark Twain
[gentoo-user] sys-fs/udev-200 and my wireless interface
From the elog which I applied carefully and the links to Flameeyes blog kindly shared in this M/L, I thought that I would have to rename *all* my interfaces. Therefore I was surprised to find that only my eth0 changed to enp11s0, while my wlan0 stayed the same. I even rebooted to make sure and had no problem connecting wirelessly. Is this how it is supposed to be? $ ifconfig -a enp11s0: flags=4163UP,BROADCAST,RUNNING,MULTICAST mtu 1492 inet 10.10.10.7 netmask 255.255.255.0 broadcast 10.10.10.255 inet6 fe80::226:b9ff:fe20:b49c prefixlen 64 scopeid 0x20link ether 00:26:b9:20:b4:9c txqueuelen 1000 (Ethernet) RX packets 38 bytes 946921086 (903.0 MiB) RX errors 0 dropped 132 overruns 0 frame 0 TX packets 346579 bytes 26003941 (24.7 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 device interrupt 17 ip6tnl0: flags=128NOARP mtu 1452 unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 txqueuelen 0 (UNSPEC) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 ip_vti0: flags=128NOARP mtu 1500 tunnel txqueuelen 0 (IPIP Tunnel) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 lo: flags=73UP,LOOPBACK,RUNNING mtu 65536 inet 127.0.0.1 netmask 255.0.0.0 inet6 ::1 prefixlen 128 scopeid 0x10host loop txqueuelen 0 (Local Loopback) RX packets 789896 bytes 914674121 (872.3 MiB) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 789896 bytes 914674121 (872.3 MiB) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 sit0: flags=128NOARP mtu 1480 sit txqueuelen 0 (IPv6-in-IPv4) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 wlan0: flags=4098BROADCAST,MULTICAST mtu 1500 ether 70:1a:04:d7:c3:09 txqueuelen 1000 (Ethernet) RX packets 0 bytes 0 (0.0 B) RX errors 0 dropped 0 overruns 0 frame 0 TX packets 0 bytes 0 (0.0 B) TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0 -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Difference between --update and --emptytree?
On Sun, 31 Mar 2013 09:09:56 -0400, Walter Dnes wrote: emerge -p --depclean generates dire warnings. I wouldn't call this dire * Always study the list of packages to be cleaned for any obvious * mistakes. Packages that are part of the world set will always * be kept. They can be manually added to this set with * `emerge --noreplace atom`. Packages that are listed in * package.provided (see portage(5)) will be removed by * depclean, even if they are part of the world set. There used to be big scary warnings in the past, but that was years ago and depclean seems very reliable now. I'd certainly trust a feature maintained by the portage devs more than a home-brewed script -- Neil Bothwick There's a fine line between fishing and standing on the shore looking like an idiot. signature.asc Description: PGP signature
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 2013-03-31 1:10 PM, Yohan Pereira yohan.pere...@gmail.com wrote: What you need to do is add the original ebuild for udev-171 to your local overlay as is. Then run emerge using the -g option see man emerge. Hmmm... I had thought that the local ebuild was gone due to it being removed from portage, but yep, there it is: myhost : Sun Mar 31, 13:42:50 : ~ # ls -al /usr portage/sys-fs/udev total 292 drwxr-xr-x 3 portage portage512 Mar 30 12:01 . drwxr-xr-x 128 portage portage 3488 Mar 31 10:31 .. -rw-r--r-- 1 rootroot 23718 Mar 30 12:01 ChangeLog -rw-r--r-- 1 rootroot105929 Mar 15 06:01 ChangeLog-2009 -rw-r--r-- 1 rootroot 10729 Mar 15 05:38 ChangeLog-2010 -rw-r--r-- 1 rootroot 11721 Mar 15 05:38 ChangeLog-2011 -rw-r--r-- 1 rootroot 23242 Mar 15 05:38 ChangeLog-2012 drwxr-xr-x 2 portage portage 88 Mar 31 10:31 files -rw-r--r-- 1 rootroot 10407 Mar 30 12:01 Manifest -rw-r--r-- 1 rootroot 1401 Mar 28 18:01 metadata.xml -rw-r--r-- 1 rootroot 16093 Feb 2 11:31 udev-171-r10.ebuild -rw-r--r-- 1 rootroot 15057 Mar 6 15:31 udev-197-r8.ebuild -rw-r--r-- 1 rootroot 14100 Mar 24 06:45 udev-198-r6.ebuild -rw-r--r-- 1 rootroot 13431 Mar 29 03:01 udev-199-r1.ebuild -rw-r--r-- 1 rootroot 13384 Mar 30 12:01 udev-200.ebuild -rw-r--r-- 1 rootroot 13388 Mar 30 12:01 udev-.ebuild myhost : Sun Mar 31, 13:42:52 : ~ # So, do I also copy the manifest file? metadata.xml? files dir? Or do I just copy the ebuild then regenerate the manifest file? Thanks Yohan...
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. And, at least now, I have got enough knowledge to know whether it affects me or not. But the sad thing is that I got most of that knowledge *after* the first of these versions without the old script was stabilized. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. And, at least now, I have got enough knowledge to know whether it affects me or not. But the sad thing is that I got most of that knowledge *after* the first of these versions without the old script was stabilized. I switched to eudev when the separate /usr thing popped up. While I am watching this thread and sort of taking mental notes, I'm hoping this is not a eudev thing, even in the future. I'm just hoping people will be able to find a solution to this that works well for them. I especially wish that for those managing a remote system with little or no physical access. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] How to prevent a dns amplification attack
Am 31.03.2013 04:08, schrieb Paul Hartman: On Thu, Mar 28, 2013 at 3:51 AM, Norman Rieß nor...@smash-net.org wrote: Hello, i am using pdns recursor to provide a dns server which should be usable for everybody.The problem is, that the server seems to be used in dns amplification attacks. I googled around on how to prevent this but did not really find something usefull. Does anyone got an idea about this? Coincidentally, yesterday US-CERT published a small article about DNS amplification attacks and mitigation strategies: http://www.us-cert.gov/ncas/alerts/TA13-088A Thanks a lot!
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 31/03/2013 20:26, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, It's more accurate to say it worked by accident rather than by design. (Sort of like how the power utility gets power to your house - if yours is anything like mine I get power despite their best efforts to not give me any ...) Anyway, the old method sucked and it sort of works for you and I because we don't add anything ourselves that trip it up. But this new method... geez lads, I just dunno. How do Windows, Mac and Android deal with this stuff? They don't seem to have any device naming problems, so what is the magic solution in use on those platforms? eudev works but I'm not sure what hoops I would have to go through to get the new udev working, most likely the same ones others here are going through now. For once, I'm not having to deal with some broken issue. knock on wood My current uptime is about 190 days. May hit it still but I'm certainly hoping I don't. Dale :-) :-) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 31/03/2013 18:41, Tanstaafl wrote: Googled and can't seem to find an answer to this... I've had FEATURES=buildpkg for some time on my system, so I already have udev-171-r10 quickpkg'd... But for the life of me, I can't seem to find instructions for how to convert /usr/portage/packages/sys-fs/udev-171-r10.tbz2 to an ebuild that I can then add to my local overlay... The quickpkg is a tarball, it does not contain an ebuild. It only contains the files installed by the ebuild. You have to have the copy of the ebuild somewhere else. This only makes sense as the way to re-install the pkg is emerge -k some_pkg, so you have to have the ebuild first before using the quickpkg. A copy of the ebuild for the *currently*installed* package is in /var/db/pkg/cat/pkg-version/*ebuild You need to grab and store a copy of it before unininstalling it and before it is removed from portage. Failing that, you can always get a copy out of the Gentoo Attic (the URL for which I can never remember but Google doesn't have that problem) Can this be done with the quickpkg command, or some other portage tool/command? Or do I have to Anyone know how to do this? I'm basically using this udev event to learn a little about how quickpkg works, so, since udev-171 is no longer in the portage tree, I want to convert my quickpkg of it to an ebuild in my local overlay so my mask will work again... then I'll back everything up, and do the update to udev... -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 31/03/2013 20:30, Tanstaafl wrote: On 2013-03-31 1:10 PM, Yohan Pereira yohan.pere...@gmail.com wrote: What you need to do is add the original ebuild for udev-171 to your local overlay as is. Then run emerge using the -g option see man emerge. Hmmm... I had thought that the local ebuild was gone due to it being removed from portage, but yep, there it is: myhost : Sun Mar 31, 13:42:50 : ~ # ls -al /usr portage/sys-fs/udev total 292 drwxr-xr-x 3 portage portage512 Mar 30 12:01 . drwxr-xr-x 128 portage portage 3488 Mar 31 10:31 .. -rw-r--r-- 1 rootroot 23718 Mar 30 12:01 ChangeLog -rw-r--r-- 1 rootroot105929 Mar 15 06:01 ChangeLog-2009 -rw-r--r-- 1 rootroot 10729 Mar 15 05:38 ChangeLog-2010 -rw-r--r-- 1 rootroot 11721 Mar 15 05:38 ChangeLog-2011 -rw-r--r-- 1 rootroot 23242 Mar 15 05:38 ChangeLog-2012 drwxr-xr-x 2 portage portage 88 Mar 31 10:31 files -rw-r--r-- 1 rootroot 10407 Mar 30 12:01 Manifest -rw-r--r-- 1 rootroot 1401 Mar 28 18:01 metadata.xml -rw-r--r-- 1 rootroot 16093 Feb 2 11:31 udev-171-r10.ebuild -rw-r--r-- 1 rootroot 15057 Mar 6 15:31 udev-197-r8.ebuild -rw-r--r-- 1 rootroot 14100 Mar 24 06:45 udev-198-r6.ebuild -rw-r--r-- 1 rootroot 13431 Mar 29 03:01 udev-199-r1.ebuild -rw-r--r-- 1 rootroot 13384 Mar 30 12:01 udev-200.ebuild -rw-r--r-- 1 rootroot 13388 Mar 30 12:01 udev-.ebuild myhost : Sun Mar 31, 13:42:52 : ~ # So, do I also copy the manifest file? metadata.xml? files dir? Or do I just copy the ebuild then regenerate the manifest file? You will need the files dir. metadata.xml is not necessary in your personal overlay. You will almost always regenerate the manifest anyway so copy the original by all means, but you'll likely overwrite it soon -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 13:44:18 -0500, Dale wrote: I'm just hoping people will be able to find a solution to this that works well for them. I especially wish that for those managing a remote system with little or no physical access. Well I just updated a headless box, followed the instructions in the news article and it just worked. I now have net0 instead of eth0. What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting :) -- Neil Bothwick When told the reason for Daylight Saving time the old Indian said... Only a white man would believe that you could cut a foot off the top of a blanket And sew it to the bottom of a blanket and have a longer blanket. signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 11:48:19 + (UTC) Nuno J. Silva (aka njsg) nunojsi...@ist.utl.pt wrote: instead of pushing a completely different (and possibly less reliable) naming scheme by default. Whilst I wouldn't want them changing on me (though if your physically changing the pci slot then you should be able to handle the number change). I find the OpenBSD method of different names like fxp0 useful because it means you can look up the manpage for that card type which as long as the documentation is good is very useful.
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 2013-03-31 3:14 PM, Alan McKinnon alan.mckin...@gmail.com wrote: A copy of the ebuild for the*currently*installed* package is in /var/db/pkg/cat/pkg-version/*ebuild Oh... so I should use that instead of what is in /usr/portage/sys-fs?
Re: [gentoo-user] Re: Udev update and persistent net rules changes
Alan McKinnon wrote: On 31/03/2013 20:26, Dale wrote: Nuno J. Silva (aka njsg) wrote: On 2013-03-31, Dale rdalek1...@gmail.com wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. I'd guess eudev will eventually do the same, although I hope that, it being a separate codebase, makes it easier to adopt some solution like the old rule generator, instead of using udev's approach. The udev upstream may have its issues, but there's actually a point in removing this, the approach there was so far was just a dirty hack. Thing is, it works for me. The old udev worked, It's more accurate to say it worked by accident rather than by design. (Sort of like how the power utility gets power to your house - if yours is anything like mine I get power despite their best efforts to not give me any ...) Anyway, the old method sucked and it sort of works for you and I because we don't add anything ourselves that trip it up. But this new method... geez lads, I just dunno. How do Windows, Mac and Android deal with this stuff? They don't seem to have any device naming problems, so what is the magic solution in use on those platforms? Well, it still works regardless of by accident or by design. On the rare occasion that I have to reboot/shutdown, when my system comes up, I still have the same network connection(s) I had before. I still have net.eth0 like I have had since I built this rig. On my old rig, same thing and I added networks cards to it, more than once I might add. Everything was consistent until I disabled the on board nic since it went bad then it got interesting because I had to configure things to let the first network card be the internet connection instead of the on board old one. I'm pretty sure that regardless of what was managing devices that I would still have had to tell it which interface to use tho. I mean, it can't exactly read my mind. lol Point is, just like the /usr mess, it's working just fine. Odd thing is, udev folks said it couldn't be fixed but the eudev folks seemed to have fixed it just fine. It seems Walter found his own fix too. Sort of like a plumber telling me I have to put with the drip when another plumber can replace the o-ring and stop the drip. So much for the first plumber. I'll loose his number for sure. Only with this, two plumbers had a better plan. One replaced the o-ring, one replaced the whole faucet. Still got rid of the drip tho. I generally look more at the results than the how. I'm not a programmer, just a user. End result is what I look for. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: instead of pushing a completely different (and possibly less reliable) naming scheme by default. Whilst I wouldn't want them changing on me (though if your physically changing the pci slot then you should be able to handle the number change). What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. -- Neil Bothwick B?#$^f, said Pooh, as line noise garbled his transmission. signature.asc Description: PGP signature
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On Sun, 31 Mar 2013 15:44:49 -0400, Tanstaafl wrote: A copy of the ebuild for the*currently*installed* package is in /var/db/pkg/cat/pkg-version/*ebuild Oh... so I should use that instead of what is in /usr/portage/sys-fs? No, you only do that if the original is not available. Copy the whole sys-fs/udev directory to your overlay then remove the files you don't need and rebuild the manifest. -- Neil Bothwick DOS: Defunct Operating System signature.asc Description: PGP signature
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On 03/31/2013 03:55 PM, Neil Bothwick wrote: On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: instead of pushing a completely different (and possibly less reliable) naming scheme by default. Whilst I wouldn't want them changing on me (though if your physically changing the pci slot then you should be able to handle the number change). What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. Social media is infectious. I was looking for a '+1' button for this... signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
Le 31/03/13 à 21:14, Alan a tapoté : On 31/03/2013 18:41, Tanstaafl wrote: But for the life of me, I can't seem to find instructions for how to convert /usr/portage/packages/sys-fs/udev-171-r10.tbz2 to an ebuild that I can then add to my local overlay... The quickpkg is a tarball, it does not contain an ebuild. It only contains the files installed by the ebuild. Wrong. See here : http://wiki.gentoo.org/wiki/Binary_package_guide#Taking_a_tbz2_apart
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31 3:37 PM, Neil Bothwick n...@digimed.co.uk wrote: What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting:) So, just ln -s net.net0 - net.lo Then after reboot, you can rm net.eth0 - net.lo ?
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 2013-03-31 3:56 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 31 Mar 2013 15:44:49 -0400, Tanstaafl wrote: A copy of the ebuild for the*currently*installed* package is in /var/db/pkg/cat/pkg-version/*ebuild Oh... so I should use that instead of what is in /usr/portage/sys-fs? No, you only do that if the original is not available. Copy the whole sys-fs/udev directory to your overlay then remove the files you don't need Well, that presupposes I know what files I need and what files I don't need... The problem is I don't... I can *guess* that all I need is the ebuild file, the files dir, and maybe the Manifest and metadata.xml files... and rebuild the manifest. Ok, I've done this, but it still wants to install udev-200... it also mentions, and I confirmed, that udev-171 is masked in /usr/portage/profiles/package.mask, so, presumably, I need to comment these out too? This is getting really ugly.
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 2013-03-31 3:16 PM, Alan McKinnon alan.mckin...@gmail.com wrote: So, do I also copy the manifest file? metadata.xml? files dir? Or do I just copy the ebuild then regenerate the manifest file? You will need the files dir. metadata.xml is not necessary in your personal overlay. You will almost always regenerate the manifest anyway so copy the original by all means, but you'll likely overwrite it soon Actually, I should have said (and I meant) regenerate it manually... ie: ebuild foo.ebuild manifest
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
On Sun, 31 Mar 2013 20:55:00 +0100 Neil Bothwick n...@digimed.co.uk wrote: What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. Fair point but wouldn't that be only if you plug in two of the same type that the names may switch? In which case there are various ways of solving the problem and name assignment may be handy in some cases, though I still think it would be good to have a man page linked to that name.
[gentoo-user] Re: Udev update and persistent net rules changes
On 2013-03-31, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 31 Mar 2013 13:44:18 -0500, Dale wrote: I'm just hoping people will be able to find a solution to this that works well for them. I especially wish that for those managing a remote system with little or no physical access.=20 Well I just updated a headless box, followed the instructions in the news article and it just worked. I now have net0 instead of eth0. What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting :) This one was mentioned and discussed in gentoo-dev. It's sad if this information didn't make it to the news item, but perhaps it was mentioned a bit too late. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On Sunday 31 Mar 2013 21:19:18 Tanstaafl wrote: On 2013-03-31 3:37 PM, Neil Bothwick n...@digimed.co.uk wrote: What the article didn't mention was that if you change your interface names, you have to create a new symlink in /etc/init.d and add it to the default runlevel. I'm glad I spotted that one before rebooting:) So, just ln -s net.net0 - net.lo Then after reboot, you can rm net.eth0 - net.lo ? Worth noting that I did not remove /etc/init.d/net.eth0 and upon rebooting a box I couldn't connect to it via ssh! This was despite having changed the firewall interface in the iptables rules to the new NIC name. Thankfully I had physical access. sshd complained that net.eth0 was not available. I deleted the /etc/init.d/net.eth0 symlink and rebooted. No more problems. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 31/03/2013 21:44, Tanstaafl wrote: On 2013-03-31 3:14 PM, Alan McKinnon alan.mckin...@gmail.com wrote: A copy of the ebuild for the*currently*installed* package is in /var/db/pkg/cat/pkg-version/*ebuild Oh... so I should use that instead of what is in /usr/portage/sys-fs? I don't know which one you should use. You are the guy sitting next to the computer in question, I'm not. You must identify and use the one you want to use. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Convert quickpkg of udev-171-r10 to local overlay...
On 31/03/2013 22:24, Tanstaafl wrote: On 2013-03-31 3:56 PM, Neil Bothwick n...@digimed.co.uk wrote: On Sun, 31 Mar 2013 15:44:49 -0400, Tanstaafl wrote: A copy of the ebuild for the*currently*installed* package is in /var/db/pkg/cat/pkg-version/*ebuild Oh... so I should use that instead of what is in /usr/portage/sys-fs? No, you only do that if the original is not available. Copy the whole sys-fs/udev directory to your overlay then remove the files you don't need Well, that presupposes I know what files I need and what files I don't need... The problem is I don't... I can *guess* that all I need is the ebuild file, the files dir, and maybe the Manifest and metadata.xml files... and rebuild the manifest. Ok, I've done this, but it still wants to install udev-200... it also mentions, and I confirmed, that udev-171 is masked in /usr/portage/profiles/package.mask, so, presumably, I need to comment these out too? This is getting really ugly. No it's not. I see what you are running into from other replies. You have apparently not read the documentation on user overlays at gentoo.org. Please find and read that first. It contains everything you need to know. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] [way OT but interesting] Massive recent DDOS attack
Any of you admin types out there have any grumpy thoughts about this article? :) Is it really just marketing BS from cloudflare, or is it solid stuff? http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
On 01/04/2013 01:12, walt wrote: Any of you admin types out there have any grumpy thoughts about this article? :) Is it really just marketing BS from cloudflare, or is it solid stuff? http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet A quick scan of the article seems to be solid stuff. Yes, they are of course trying to make themselves look good (who wouldn't?) but they also seem to be sticking to the facts as well. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: Udev update and persistent net rules changes
On 01/04/13 01:01, Dale wrote: Pandu Poluan wrote: Since it's obvious that upsteam has this my way or the highway mentality, I'm curious about whether eudev (and mdev) exhibits the same behavior... Rgds, -- I synced yesterday and I didn't see the news alert. Last eudev update was in Feb. so I *guess* not. It seems to be a udev thing. That is why I mentioned eudev to someone else that was having this issue with a server setup. Dale :-) :-) Have not seen it yet (eudev), but something interesting is I am moving to a small cloud of libvirt managed vm instances for my services and instead of having to delete the net rules file in each instance (because the mac address is changing) it creates a new eth0 for the new mac address, and moved the old to eth1 - handy as I am using a base image and spawning off a child from a snap for each instance - one less annoyance to worry about! Seemed to happen about the time of the last eudev update, need to look into it more. BillK
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
On 03/31/2013 07:12 PM, walt wrote: Any of you admin types out there have any grumpy thoughts about this article? :) Is it really just marketing BS from cloudflare, or is it solid stuff? http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet Can't tell one way or another. Certainly the bulk of the events described are true. Certainly, it's in CF's interest to describe how they're thwarting a massive DDOS. And, certainly, they'd lose virtually all credibility if they were blowing smoke. Lose credibility, and they'd lose a ton of business. Frankly, I'm *inclined* to believe their description of events on that basis alone. But that's not absolute. It's also worth noting who they're protecting, and who the aggressor is. The organization they're protecting is a high-profile target. The organization they're protecting against is one whose businesses are heavily impacted by the latter, *and* who don't share a positive reputation among most. That said, when someone in here linked to a spamhaus page a few days ago, my local CloudFlare cache didn't have a copy of it, so I suspect spamhaus hasn't been weathering the storm particularly well. I'm also using CloudFlare for my site (they have a free tier which is frankly wonderful), and I've observed that whatever means I put in place to protect myself through them, it's not possible to get 100% coverage; for CF to work for you, you need to have a public IP address their servers can query. So long as you have a public IP address, you can be targeted; it's just a matter of discovering what that IP is. That IP could be discovered any of a variety of ways, particularly if someone is able to induce your server to send data outbound. (i.e. an email where the origin exists in the message headers.) For at least a couple weeks now, I've been a direct target of some kind of attack by someone who holds some kind of weird grudge. Originally, it was a simple SYN flood, but it's lately taken to be a flood of RST packets claiming to be from a particular CloudFlare IP; the attacker is trying to disrupt service by terminating proxied connections. Anyway, if you don't need SSL, I highly recommend CloudFlare's free tier. If you do need SSL, they have tiers which support that...but I don't have a budget to spend on it. (OTOH, it's nice enough that my average page load times have plummeted...and I now have a free global proxy cache network, despite my only having one backend server...) signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
On 3/31/2013 19:12, walt wrote: Any of you admin types out there have any grumpy thoughts about this article? :) Is it really just marketing BS from cloudflare, or is it solid stuff? http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet Some other good reads: http://cluepon.net/ras/gizmodo http://instituut.net/~job/cb3rob-spamhaus-hijack-21-mar-2013.txt https://greenhost.nl/2013/03/21/spam-not-spam-tracking-hijacked-spamhaus-ip/ -- staticsafe O ascii ribbon campaign - stop html mail - www.asciiribbon.org Please don't top post - http://goo.gl/YrmAb Don't CC me! I'm subscribed to whatever list I just posted on.
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
Am 01.04.2013 01:12, schrieb walt: Any of you admin types out there have any grumpy thoughts about this article? :) Is it really just marketing BS from cloudflare, or is it solid stuff? http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet and since pretty much every technological site PLUS a lot of mainstream news sites reported that attack days ago, it is really great to see ANOTHER thread spawned by this non-news.
Re: [Bulk] [gentoo-user] Re: Udev update and persistent net rules changes
Am 31.03.2013 21:55, schrieb Neil Bothwick: On Sun, 31 Mar 2013 15:40:09 +0100, Kevin Chadwick wrote: instead of pushing a completely different (and possibly less reliable) naming scheme by default. Whilst I wouldn't want them changing on me (though if your physically changing the pci slot then you should be able to handle the number change). What about USB network adaptors? A user may not even realise they plugged it into a different USB slot from last time, yet the device name changes. congratulation, you just found another reason why today's udev sucks.
[gentoo-user] Udev 200 : dhcpcd problem + solution
I've spent a lot of today trying to fix a glitch in starting 'dhcpcd' after upgrading to udev-200 ; I outlined it in a msg to gentoo-dev . When I tried to start my I/net connection, I got this : root:501 ~ dhcpcd dhcpcd[831]: version 5.6.7 starting ... [delay] ^C ... [long delay] dhcpcd[831]: no interfaces have a carrier dhcpcd[831]: forked to background, child pid 857 So having killed it, I restarted had no problem : root:502 ~ dhcpcd dhcpcd[866]: version 5.6.7 starting dhcpcd[866]: enp5s0: sending IPv6 Router Solicitation dhcpcd[866]: enp5s0: rebinding lease of 192.168.1.2 dhcpcd[866]: enp5s0: acknowledged 192.168.1.2 from 192.168.1.1 dhcpcd[866]: enp5s0: checking for 192.168.1.2 dhcpcd[866]: enp5s0: sending IPv6 Router Solicitation dhcpcd[866]: enp5s0: leased 192.168.1.2 for 86400 seconds dhcpcd[866]: forked to background, child pid 884 Looking at /var/log/syslog , I saw : 13:11:16 dhcpcd[831]: version 5.6.7 starting 13:12:16 klogd: r8169 :05:00.0: enp5s0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-2) 13:12:16 klogd: r8169 :05:00.0: enp5s0: link down 13:12:16 klogd: r8169 :05:00.0: enp5s0: link down 13:12:16 klogd: IPv6: ADDRCONF(NETDEV_UP): enp5s0: link is not ready 13:12:17 dhcpcd[831]: no interfaces have a carrier 13:12:17 dhcpcd[831]: forked to background, child pid 857 13:12:17 dhcpcd[857]: received SIGINT, stopping 13:12:17 dhcpcd[857]: enp5s0: removing interface 13:12:18 klogd: r8169 :05:00.0: enp5s0: link up 13:12:18 klogd: IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready 13:12:34 dhcpcd[866]: version 5.6.7 starting 13:12:34 dhcpcd[866]: enp5s0: sending IPv6 Router Solicitation 13:12:34 dhcpcd[866]: enp5s0: rebinding lease of 192.168.1.2 13:12:34 dhcpcd[866]: enp5s0: acknowledged 192.168.1.2 from 192.168.1.1 13:12:34 dhcpcd[866]: enp5s0: checking for 192.168.1.2 13:12:38 dhcpcd[866]: enp5s0: sending IPv6 Router Solicitation 13:12:39 dhcpcd[866]: enp5s0: leased 192.168.1.2 for 86400 seconds 13:12:39 dhcpcd[866]: forked to background, child pid 884 It seems that the new set-up with the device name created by the kernel requires the firmware to be built into the kernel. This is not mentioned in the recent news item. Google led to a Gentoo Forum thread which was unusually helpful (grin): http://forums.gentoo.org/viewtopic-t-899002-start-0.html This suggested the lines CONFIG_PREVENT_FIRMWARE_BUILD=y [NB this is incorrect] CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE=rtl8168e-2.fw [NB I needed '-3'] CONFIG_EXTRA_FIRMWARE_DIR=/lib/firmware I was using kernel 3.5.3 , so I updated to 3.8.5 configured it : I had to change the 1st line to 'n' -- mb a typo in the original msg -- to change .config manually to add '/lib/' before 'firmware', which 'make menuconfig' insisted on using without allowing editing. The compile command is make make firmware_install make modules_install Once the kernel was compiled + installed I had rebooted, I got : root:501 ~ dhcpcd dhcpcd[834]: version 5.6.7 starting dhcpcd[834]: no interfaces have a carrier dhcpcd[834]: forked to background, child pid 846 despite the 2nd line of output, the connection had been established. 'syslog' now reads : dhcpcd[834]: version 5.6.7 starting klogd: r8169 :05:00.0 enp5s0: link down klogd: IPv6: ADDRCONF(NETDEV_UP): enp5s0: link is not ready klogd: r8169 :05:00.0 enp5s0: link down dhcpcd[834]: no interfaces have a carrier dhcpcd[834]: forked to background, child pid 846 dhcpcd[846]: enp5s0: waiting for carrier dhcpcd[846]: sit0: unsupported interface type 308, falling back to ethernet dhcpcd[846]: sit0: broadcasting for a lease dhcpcd[846]: enp5s0: carrier acquired klogd: r8169 :05:00.0 enp5s0: link up klogd: IPv6: ADDRCONF(NETDEV_CHANGE): enp5s0: link becomes ready dhcpcd[846]: enp5s0: sending IPv6 Router Solicitation dhcpcd[846]: enp5s0: sendmsg: Cannot assign requested address dhcpcd[846]: enp5s0: rebinding lease of 192.168.1.2 dhcpcd[846]: enp5s0: acknowledged 192.168.1.2 from 192.168.1.1 dhcpcd[846]: enp5s0: checking for 192.168.1.2 dhcpcd[846]: enp5s0: sending IPv6 Router Solicitation dhcpcd[846]: enp5s0: sending IPv6 Router Solicitation dhcpcd[846]: enp5s0: leased 192.168.1.2 for 86400 seconds I'm not sure what 'sit0' is, but it doesn't seem to affect the outcome. HTH others who may face the same problem. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
130331 walt wrote: Any of you admin types out there have any grumpy thoughts about this ? http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet There was a good story in 'Guardian' : http://www.guardian.co.uk/commentisfree/2013/mar/29/cyberwar-spun-shoddy-journalism -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
[gentoo-user] ZFS wiki confusion
Anyone got ZFS working on their Gentoo install? I'm contemplating it, but the wiki[1] confuses me a bit. Specifically, section '3 Installing into the kernel directory (for static installs)' states: This will generate the needed files, and copy them into the kernel sources directory. root # (cd /var/tmp/portage/sys-kernel/spl-/work/spl- ./copy-builtin /usr/src/linux) root # (cd /var/tmp/portage/sys-fs/zfs-kmod-/work/zfs-kmod-/ ./copy-builtin /usr/src/linux) After this, you just need to edit the kernel config to enable CONFIG_SPL and CONFIG_ZFS and emerge the zfs binaries. root # mkdir -p /etc/portage/profile root # echo 'sys-fs/zfs -kernel-builtin' /etc/portage/profile/package.use.mask root # echo 'sys-fs/zfs kernel-builtin' /etc/portage/package.use root # emerge -1v sys-fs/zfs The echo's only need to be run once, but the emerge needs to be run every time you install a new version of zfs. Do you really need to copy the files into the kernel tree? WTD is a 'static install' in this context? 'emerge zfs' shows: Calculating dependencies... done! [ebuild N ] sys-fs/zfs-0.6.1 USE=rootfs -custom-cflags (-kernel-builtin) -static-libs -test-suite 1,500 kB [ebuild N ] sys-fs/zfs-kmod-0.6.1 USE=rootfs -custom-cflags -debug 0 kB [ebuild N ] sys-kernel/spl-0.6.1 USE=-custom-cflags -debug -debug-log 209 kB which seems to pull in the daemon and the kmod so wouldn't the zfs-kmod ebuild build against the current kernel and drop in the modules directory all by itself much like any of the 100s of FUSE modules do? Any clarification on the install process would be appreciated. [1] - http://wiki.gentoo.org/wiki/ZFS -- Douglas J Hunley (doug.hun...@gmail.com) Twitter: @hunleyd Web: douglasjhunley.com G+: http://goo.gl/sajR3
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
On 03/31/2013 10:00 PM, Philip Webb wrote: 130331 walt wrote: Any of you admin types out there have any grumpy thoughts about this ? http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet There was a good story in 'Guardian' : http://www.guardian.co.uk/commentisfree/2013/mar/29/cyberwar-spun-shoddy-journalism The Gizmodo article that Guardian article lauds irritated the hell out of me. Certainly it was unlikely for the global Internet to collapse. However, from the details I've read, there was a risk of one or two IXs failing, and that would have *serious* regional effects. Whether a chunk of Europe dropping offline qualifies as breaking the Internet is an interesting question. The answer probably depends on whether or not you're on that continent... signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
on 2013-03-31 at 23:05 Michael Mol wrote: On 03/31/2013 10:00 PM, Philip Webb wrote: There was a good story in 'Guardian' : http://www.guardian.co.uk/commentisfree/2013/mar/29/cyberwar-spun-shoddy-journalism The Gizmodo article that Guardian article lauds irritated the hell out of me. [...] Whether a chunk of Europe dropping offline qualifies as breaking the Internet is an interesting question. i don't live in europe. i live in a small country in south america. i don't read the press and i don't have tv. i'm mostly uncontaminated by the debris produced by journalism. today i asked my girlfriend if she had also noted that the internet has been very slow for the last week or so. perhaps it was a problem with my connection. it was she who told me that the problem with the internet had been mentioned in the news (unlike me, she does watch tv and read the news). i'm glad for all the people who weren't affected. but whatever it was, i've been suffering the consequences. so i'm more than irritated by the assholes minimizing the problem, or treating this as non-news.
Re: [gentoo-user] [way OT but interesting] Massive recent DDOS attack
luis jure wrote: on 2013-03-31 at 23:05 Michael Mol wrote: On 03/31/2013 10:00 PM, Philip Webb wrote: There was a good story in 'Guardian' : http://www.guardian.co.uk/commentisfree/2013/mar/29/cyberwar-spun-shoddy-journalism The Gizmodo article that Guardian article lauds irritated the hell out of me. [...] Whether a chunk of Europe dropping offline qualifies as breaking the Internet is an interesting question. i don't live in europe. i live in a small country in south america. i don't read the press and i don't have tv. i'm mostly uncontaminated by the debris produced by journalism. today i asked my girlfriend if she had also noted that the internet has been very slow for the last week or so. perhaps it was a problem with my connection. it was she who told me that the problem with the internet had been mentioned in the news (unlike me, she does watch tv and read the news). i'm glad for all the people who weren't affected. but whatever it was, i've been suffering the consequences. so i'm more than irritated by the assholes minimizing the problem, or treating this as non-news. Until this thread popped up, I hadn't heard about it either. I hadn't noticed any slowness but I wouldn't have known it happened either unless Walt posted it or someone else did. Me, I read the article. Also thought is was neat and sort of learned something too. Thanks Walt. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
[gentoo-user] [OT] Perixx PERIPAD-501 with Linux?
Hi, are there any experience regarding the Perixx PERIPAD-501 when used in conjunction with Linux? Will it work? Are there any limitations? Thank you very much in advance for any help! Best regards, mcc
