[gentoo-user] abi_x86_32
I recently switched from no- to multilib. In yesterday's emerge I got tens of blockers due to conflict with emul-linux-x86-xlibs-20130224. I solved as suggested in http://forums.gentoo.org/viewtopic-t-953900.html?sid=f7a643eca8ec01540164578f372c374f and http://bugs.gentoo.org/461608 that is by adding abi_x86_32 to USE and unmasking emul-linux-x86-xlibs-20130224-r1, but didn't really understand what I was doing. Can anybody shed some light on this USE flag and what's going on with multilib? thanks, raffaele
Re: [gentoo-user] Re: udev blocks systemd etc
On 28/03/2013 04:56, Michael Mol wrote: On 03/27/2013 05:51 PM, Alan McKinnon wrote: On 27/03/2013 22:41, Michael Mol wrote: The case for systemd is twofold: ... 2) Reduce the amount of CPU and RAM consumed when you're talking about booting tens of thousands of instances simultaneously across your entire infrastructure, or when your server instance might be spun up and down six times over the course of a single day. I seems to me that this is rather a niche quite-specialized case (albeit a rather large instance of a niche case). In which case it would be better implemented as Redhat MagicSauce for their cloud environment where it would be exactly tuned to that case's need. But it's a great deal cheaper to convince volunteers and package maintainers to put in the time to build the necessary service files of their own accord. Add in the complexity of parallel boot, and you can induce upstream to fix their own race-driven bugs rather than have to pay for that development directly. I don't follow the thought stream here Michael. It feels like there's a word or a sentence missing (it's just not hanging together) -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: udev blocks systemd etc
On Thu, March 28, 2013 07:59, Alan McKinnon wrote: On 28/03/2013 04:56, Michael Mol wrote: On 03/27/2013 05:51 PM, Alan McKinnon wrote: On 27/03/2013 22:41, Michael Mol wrote: The case for systemd is twofold: ... 2) Reduce the amount of CPU and RAM consumed when you're talking about booting tens of thousands of instances simultaneously across your entire infrastructure, or when your server instance might be spun up and down six times over the course of a single day. I seems to me that this is rather a niche quite-specialized case (albeit a rather large instance of a niche case). In which case it would be better implemented as Redhat MagicSauce for their cloud environment where it would be exactly tuned to that case's need. But it's a great deal cheaper to convince volunteers and package maintainers to put in the time to build the necessary service files of their own accord. Add in the complexity of parallel boot, and you can induce upstream to fix their own race-driven bugs rather than have to pay for that development directly. I don't follow the thought stream here Michael. It feels like there's a word or a sentence missing (it's just not hanging together) Alan, I think what Michael is trying to say is that by getting other distros to package systemd, other distros will help RedHat to find and fix the problems systemd is causing. -- Joost
[gentoo-user] How to prevent a dns amplification attack
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? Regards, Norman
Re: [gentoo-user] How to prevent a dns amplification attack
Typically you would just allow recursion from networks you trust. Why are you making your server available to everyone? Read this one? https://developers.google.com/speed/public-dns/docs/security
[gentoo-user] Re: [gentoo-user] user folder in path when mounting
Среда, 27 марта 2013, 16:05 -07:00 от Grant emailgr...@gmail.com: I've been mounting my external HD in thunar. When I clicked the device icon, the HD was mounted to /media/VOLUME_LABEL/. Now I see the path has changed to /run/media/grant/VOLUME_LABEL/ and the grant folder is: drwxr-x---+ 3 root root which I think is preventing my automated remote backups from working because the backup user's home directory which contains authorized_keys is on the backup HD. What is the right way to get this working again? - Grant udev rules maybe.
[gentoo-user] Re: [gentoo-user] Sync, emerge -puND world, and WHAM!!! ~100 packages to merge.
Среда, 27 марта 2013, 18:09 UTC от Alan Mackenzie a...@muc.de: Hi, Gentoo! Has anybody else seen this? I did a sync, then emerge -puND world and got a list of ~100 packages to merge. About a third of them seem to be new perl stuff, 13 packages with gnome, and a lot of this and that. Most worrying is sys-fs/udisks-2.1.0. Should I be worried about this (all my other udev-ish stuff is up to date), or will it just work? But getting such a large update, all at once, seems worrying. Should I worry about anything, or just plough ahead with the update? -- Alan Mackenzie (Nuremberg, Germany). depends on how long it's been since you had the last uodate
Re: [gentoo-user] set eth0:0 on boot....
Thank you! Helped me very much Tamer Am 26.03.2013 23:02, schrieb Alan McKinnon: On 26/03/2013 23:55, Tamer Higazi wrote: Hi people! I am looking for a way, to set eth0:0 at the moment the system is booting is there a way?! I always have to set it by hand by doing: ifconfig eth0:0 192.168.2.100 I would kindly thank you having a sollution for me. /usr/share/doc/openrc-version/net.example.bz2
[gentoo-user] gnustep-base-1.24.3 fails to merge....
Hi people! I can't update on my gentoo box gnustep-base. Always I get the error I don't seem to be able to use your Objective-C compiler to produce working binaries! Please check your Objective-C compiler installation. If you are using gcc-3.x make sure that your compiler's libgcc_s and libobjc can be found by the dynamic linker - usually that requires you to play with LD_LIBRARY_PATH or /etc/ld.so.conf. Please refer to your compiler installation instructions for more help. configure: error: The Objective-C compiler does not work or is not installed properly. Here is the complete log and the gcc info. I remerged gcc with all necessary flags, but nothing changed so far. gnustep-base log: http://pastebin.com/raw.php?i=6D42zFpP gcc info: http://pastebin.com/raw.php?i=Qw5hBW0W for any advises, I am thankfully. Tamer
Re: [gentoo-user] Re: [gentoo-user] Sync, emerge -puND world, and WHAM!!! ~100 packages to merge.
On Thu, Mar 28, 2013 at 01:48:21PM +0400, the guard wrote: Среда, 27 марта 2013, 18:09 UTC от Alan Mackenzie a...@muc.de: Hi, Gentoo! Has anybody else seen this? I did a sync, then emerge -puND world and got a list of ~100 packages to merge. About a third of them seem to be new perl stuff, 13 packages with gnome, and a lot of this and that. Most worrying is sys-fs/udisks-2.1.0. Should I be worried about this (all my other udev-ish stuff is up to date), or will it just work? But getting such a large update, all at once, seems worrying. Should I worry about anything, or just plough ahead with the update? -- Alan Mackenzie (Nuremberg, Germany). depends on how long it's been since you had the last uodate A couple of days at most. I've never seen such a large update, except for when I'd just installed Gentoo. -- Alan Mackenzie (Nuremberg, Germany).
Re: [gentoo-user] Re: [gentoo-user] Sync, emerge -puND world, and WHAM!!! ~100 packages to merge.
On 28/03/13 11:52, Alan Mackenzie wrote: On Thu, Mar 28, 2013 at 01:48:21PM +0400, the guard wrote: Среда, 27 марта 2013, 18:09 UTC от Alan Mackenzie a...@muc.de: Hi, Gentoo! Has anybody else seen this? I did a sync, then emerge -puND world and got a list of ~100 packages to merge. About a third of them seem to be new perl stuff, 13 packages with gnome, and a lot of this and that. Most worrying is sys-fs/udisks-2.1.0. Should I be worried about this (all my other udev-ish stuff is up to date), or will it just work? But getting such a large update, all at once, seems worrying. Should I worry about anything, or just plough ahead with the update? -- Alan Mackenzie (Nuremberg, Germany). depends on how long it's been since you had the last uodate A couple of days at most. I've never seen such a large update, except for when I'd just installed Gentoo. I recently had ‘emerge -avutND’ throw 713 packages at me after not updating for a couple of weeks. It took me a few days to get it back to an updated state but I managed. ~100 packages is not unusual if you don't update for a week or so, especially if something gets an update that other things depend on at which point it might remerge all those packages as well. I wouldn't worry. -- Mateusz K.
Re: [gentoo-user] Re: udev blocks systemd etc
On 03/28/2013 03:51 AM, J. Roeleveld wrote: On Thu, March 28, 2013 07:59, Alan McKinnon wrote: On 28/03/2013 04:56, Michael Mol wrote: On 03/27/2013 05:51 PM, Alan McKinnon wrote: On 27/03/2013 22:41, Michael Mol wrote: The case for systemd is twofold: ... 2) Reduce the amount of CPU and RAM consumed when you're talking about booting tens of thousands of instances simultaneously across your entire infrastructure, or when your server instance might be spun up and down six times over the course of a single day. I seems to me that this is rather a niche quite-specialized case (albeit a rather large instance of a niche case). In which case it would be better implemented as Redhat MagicSauce for their cloud environment where it would be exactly tuned to that case's need. But it's a great deal cheaper to convince volunteers and package maintainers to put in the time to build the necessary service files of their own accord. Add in the complexity of parallel boot, and you can induce upstream to fix their own race-driven bugs rather than have to pay for that development directly. I don't follow the thought stream here Michael. It feels like there's a word or a sentence missing (it's just not hanging together) Alan, I think what Michael is trying to say is that by getting other distros to package systemd, other distros will help RedHat to find and fix the problems systemd is causing. Exactly this. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Re: udev blocks systemd etc
On 03/28/2013 12:28 AM, Grant Edwards wrote: On 2013-03-27, Michael Mol mike...@gmail.com wrote: The case for systemd is twofold: 1) Boot-to-desktop session management by one tool. Ah, the old universal generic tool approach. I've seen a lot of money and time poured into black-hole projects with names containing words like universal and generic, so I don't really like the sound of that. [Is that the right response for somebody who started using V7 Unix on a PDP11?] It has theoretical advantages. Avoiding an impedance mismatch makes turn-key systems that much easier. (I expect that to apply to embedded systems like phones and consumer network gear, but we'll see how it plays out. RAM is cheap, and getting cheaper...I just configured a Netgear router with 128MB of RAM...) (The same thing that launches your cron daemon is what launches your favorite apps when you log in.) The only app that runs when I log in is bash. Then I usually start XFCE from the command line -- but not always. 2) Reduce the amount of CPU and RAM consumed when you're talking about booting tens of thousands of instances simultaneously across your entire infrastructure, or when your server instance might be spun up and down six times over the course of a single day. It sounds like systemd really isn't intended for the likes of me. Indeed. Are there people who reboot their machines every few minutes and therefore need to shave a few seconds off their boot time? On-demand server contexts, yes. Thanks for the explanation -- I never would have guessed that's how the whole cloud thing worked. Private clouds work the same way. As business penetration of cloud services grow, I expect we'll see backlash as major outages occur. Imagine if cyberbunker had attacked Google rather than Spamhaus earlier this week. The scale of that attack reached the upper limit of what the Internet's infrastructure is capable of carrying...nobody, not even companies with dozens of data centers in a distributed architecture, can ultimately bear that. Organizations which have grown comfortable in an age of reliable Internet access and cheap cloud services are going to discover they still have operational needs that must go on even without network access. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Is 'MAKEOPTS=--jobs --load-average=5' silly?
On Wednesday 27 March 2013 18:16:22 Walter Dnes wrote: OK, I'll go with... MAKEOPTS=-j2 --load-average=3 This box is an i5 with four single-threaded CPUs and I limit the average load to 8. Since emerge is running at niceness=3 the desktop remains responsive throughout. I used not to limit the load at all and KDE was still fine to work with. I sometimes think that with modern systems there's no need to impose limits of my own since the kernel can cope well by itself. In fact I'm going to remove the load limit and see how I get on. -- Peter
Re: [gentoo-user] Re: udev blocks systemd etc
On 28/03/2013 15:16, Michael Mol wrote: On 03/28/2013 03:51 AM, J. Roeleveld wrote: On Thu, March 28, 2013 07:59, Alan McKinnon wrote: On 28/03/2013 04:56, Michael Mol wrote: On 03/27/2013 05:51 PM, Alan McKinnon wrote: On 27/03/2013 22:41, Michael Mol wrote: The case for systemd is twofold: ... 2) Reduce the amount of CPU and RAM consumed when you're talking about booting tens of thousands of instances simultaneously across your entire infrastructure, or when your server instance might be spun up and down six times over the course of a single day. I seems to me that this is rather a niche quite-specialized case (albeit a rather large instance of a niche case). In which case it would be better implemented as Redhat MagicSauce for their cloud environment where it would be exactly tuned to that case's need. But it's a great deal cheaper to convince volunteers and package maintainers to put in the time to build the necessary service files of their own accord. Add in the complexity of parallel boot, and you can induce upstream to fix their own race-driven bugs rather than have to pay for that development directly. I don't follow the thought stream here Michael. It feels like there's a word or a sentence missing (it's just not hanging together) Alan, I think what Michael is trying to say is that by getting other distros to package systemd, other distros will help RedHat to find and fix the problems systemd is causing. Exactly this. Ah, a definition of getting that I was heretofore unfamiliar with. Obviously getting doesn't mean what I think it means, it means forcing without giving the other party much of a choice in the matter by ripping out essential infrastructure and replacing it with something tuned to RedHat, and only RedHat's, needs. Ok, I got it now. Thanks for clearing that up. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] How to prevent a dns amplification attack
Turn off this unnecessary crap? Am 28.03.2013 09:52 schrieb Norman Rieß nor...@smash-net.org: 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? Regards, Norman
Re: [gentoo-user] Re: udev blocks systemd etc
On 03/28/2013 10:35 AM, Alan McKinnon wrote: On 28/03/2013 15:16, Michael Mol wrote: On 03/28/2013 03:51 AM, J. Roeleveld wrote: On Thu, March 28, 2013 07:59, Alan McKinnon wrote: On 28/03/2013 04:56, Michael Mol wrote: On 03/27/2013 05:51 PM, Alan McKinnon wrote: On 27/03/2013 22:41, Michael Mol wrote: The case for systemd is twofold: ... 2) Reduce the amount of CPU and RAM consumed when you're talking about booting tens of thousands of instances simultaneously across your entire infrastructure, or when your server instance might be spun up and down six times over the course of a single day. I seems to me that this is rather a niche quite-specialized case (albeit a rather large instance of a niche case). In which case it would be better implemented as Redhat MagicSauce for their cloud environment where it would be exactly tuned to that case's need. But it's a great deal cheaper to convince volunteers and package maintainers to put in the time to build the necessary service files of their own accord. Add in the complexity of parallel boot, and you can induce upstream to fix their own race-driven bugs rather than have to pay for that development directly. I don't follow the thought stream here Michael. It feels like there's a word or a sentence missing (it's just not hanging together) Alan, I think what Michael is trying to say is that by getting other distros to package systemd, other distros will help RedHat to find and fix the problems systemd is causing. Exactly this. Ah, a definition of getting that I was heretofore unfamiliar with. Obviously getting doesn't mean what I think it means, it means forcing without giving the other party much of a choice in the matter by ripping out essential infrastructure and replacing it with something tuned to RedHat, and only RedHat's, needs. Ok, I got it now. Thanks for clearing that up. In theory, it's supposed to be an additional option when choosing an init system, rather than forcing a wholesale switchover across the Linux infrastructure. If it weren't for the upstream udev behavior, that's probably what it would still be. (Perhaps eudev will be a resolution to this, perhaps not. Only time will tell.) Apart from the issues around udev, I don't expect this to get in the way a whole lot. Converting systemd unit files to classic init scripts shouldn't prove to be difficult to largely automate. Getting systemic race issues fixed is probably going to be a good thing. Getting daemon writers to architect their software in ways that survive parallel booting will probably be a good thing. Code quality outside of systemd *should* ultimately improve as a result of all this...but it's a valid question whether or not the things being fixed would be worth the effort if the new parallel boot agents hadn't begun taking hold. On the other hand, it's equally valid to note that, with SMP architectures becoming pervasive, it was only a matter of time before traditionally-serial systems would be pressured into taking advantage of them. This too, shall pass. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] How to prevent a dns amplification attack
On 03/28/2013 04:51 AM, Norman Rieß 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? I'm not sure it can be done. You can't make a resolver available to everybody without somebody in that everybody group abusing it, and that's exacly what happens in a DNS amplification attack. Restrict your resolver to be accessible only to your network or, at most, those of the specific group of people you're seeking to help. You *might* try restricting the resolver to only respond to TCP requests rather than UDP requests, but if the resolver sends response data along with that first SYN+ACK, then nothing is solved, and you've opened yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver went offline as a result of a SYN flood, at least it wouldn't be part of an amplification attack any longer...) signature.asc Description: OpenPGP digital signature
[gentoo-user] Updating our live servers. I'm scared!
Hello Everyone, Just got a ticket assigned to me where we need to update our production servers. uname -a Linux noun 3.4.9-gentoo #2 SMP Sat Oct 13 09:35:07 EDT 2012 x86_64 Intel(R) Xeon(TM) CPU 3.60GHz GenuineIntel GNU/Linux eselect [18] hardened/linux/amd64 * I don't think they have been updated since the initial install and wanted to get a little feedback on some safe practices and methods that should be performed before and while doing so. Thanks in Advance, Nick.
Re: [gentoo-user] Updating our live servers. I'm scared!
On Thu, Mar 28, 2013 at 11:38 AM, Nick Khamis sym...@gmail.com wrote: Hello Everyone, Just got a ticket assigned to me where we need to update our production servers. uname -a Linux noun 3.4.9-gentoo #2 SMP Sat Oct 13 09:35:07 EDT 2012 x86_64 Intel(R) Xeon(TM) CPU 3.60GHz GenuineIntel GNU/Linux eselect [18] hardened/linux/amd64 * I don't think they have been updated since the initial install and wanted to get a little feedback on some safe practices and methods that should be performed before and while doing so. Thanks in Advance, Nick. Personally, I would recommend pulling an rsync (databases and such might cause a hiccup with that) of one of them to a nonessential system and testing updating there, building packages (assuming matching use flags, etc, across your systems), documenting the pitfalls you run into as you go. After you're up to date there, run through and test it again from a base copy, then test the actual services to ensure changes to them don't hose your environment's configuration, and once that's good, it then depends entirely on what failover, or downtime allowances you have available. If you have no failover to rely on, and can't afford enough downtime to update the system in place from the packages you've built, clone each off, update, then migrate the changes that've occured in the time between... time consuming, and requires a lot of care, but doable. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] How to prevent a dns amplification attack
On Mar 28, 2013 10:38 PM, Michael Mol mike...@gmail.com wrote: On 03/28/2013 04:51 AM, Norman Rieß 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? I'm not sure it can be done. You can't make a resolver available to everybody without somebody in that everybody group abusing it, and that's exacly what happens in a DNS amplification attack. Restrict your resolver to be accessible only to your network or, at most, those of the specific group of people you're seeking to help. You *might* try restricting the resolver to only respond to TCP requests rather than UDP requests, but if the resolver sends response data along with that first SYN+ACK, then nothing is solved, and you've opened yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver went offline as a result of a SYN flood, at least it wouldn't be part of an amplification attack any longer...) Can't we rate limit UDP DNS request? E.g., limit each source IP to, let's say, 1 UDP per second? That should be doable easily using iptables. Rgds, --
Re: [gentoo-user] How to prevent a dns amplification attack
On 03/28/2013 12:06 PM, Pandu Poluan wrote: On Mar 28, 2013 10:38 PM, Michael Mol mike...@gmail.com mailto:mike...@gmail.com wrote: On 03/28/2013 04:51 AM, Norman Rieß 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? I'm not sure it can be done. You can't make a resolver available to everybody without somebody in that everybody group abusing it, and that's exacly what happens in a DNS amplification attack. Restrict your resolver to be accessible only to your network or, at most, those of the specific group of people you're seeking to help. You *might* try restricting the resolver to only respond to TCP requests rather than UDP requests, but if the resolver sends response data along with that first SYN+ACK, then nothing is solved, and you've opened yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver went offline as a result of a SYN flood, at least it wouldn't be part of an amplification attack any longer...) Can't we rate limit UDP DNS request? E.g., limit each source IP to, let's say, 1 UDP per second? That should be doable easily using iptables. That makes the resolver highly unreliable for normal use. Many sites trigger resource grabs from 10-15 different domains. If all but the first request is dropped due to rate limiting, you're going to have a very, very broken experience. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] Updating our live servers. I'm scared!
So basically rsync configs and databases first? When issuing updates to world and so no. What is the safest process/order to sync portage, and update world? I have seen a number of flags various example use, and was wondering if someone can give me the safest and equally effective commands with flags included. Thanks again, Nick. On 3/28/13, Joshua Murphy poiso...@gmail.com wrote: On Thu, Mar 28, 2013 at 11:38 AM, Nick Khamis sym...@gmail.com wrote: Hello Everyone, Just got a ticket assigned to me where we need to update our production servers. uname -a Linux noun 3.4.9-gentoo #2 SMP Sat Oct 13 09:35:07 EDT 2012 x86_64 Intel(R) Xeon(TM) CPU 3.60GHz GenuineIntel GNU/Linux eselect [18] hardened/linux/amd64 * I don't think they have been updated since the initial install and wanted to get a little feedback on some safe practices and methods that should be performed before and while doing so. Thanks in Advance, Nick. Personally, I would recommend pulling an rsync (databases and such might cause a hiccup with that) of one of them to a nonessential system and testing updating there, building packages (assuming matching use flags, etc, across your systems), documenting the pitfalls you run into as you go. After you're up to date there, run through and test it again from a base copy, then test the actual services to ensure changes to them don't hose your environment's configuration, and once that's good, it then depends entirely on what failover, or downtime allowances you have available. If you have no failover to rely on, and can't afford enough downtime to update the system in place from the packages you've built, clone each off, update, then migrate the changes that've occured in the time between... time consuming, and requires a lot of care, but doable. -- Poison [BLX] Joshua M. Murphy
Re: [gentoo-user] Updating our live servers. I'm scared!
On 03/28/2013 11:38 AM, Nick Khamis wrote: Hello Everyone, Just got a ticket assigned to me where we need to update our production servers. uname -a Linux noun 3.4.9-gentoo #2 SMP Sat Oct 13 09:35:07 EDT 2012 x86_64 Intel(R) Xeon(TM) CPU 3.60GHz GenuineIntel GNU/Linux eselect [18] hardened/linux/amd64 * I don't think they have been updated since the initial install and wanted to get a little feedback on some safe practices and methods that should be performed before and while doing so. This isn't that old, you'll be fine. First run an emerge --sync to update the tree. Then list everything it wants to upgrade: emerge -puDN1 world Once you have that list, go through a few at a time, updating non-essential packages. For example, emerge -u1 timezone-data man-pages ... Every once in a while, run a revdep-rebuild. If you have service monitoring (e.g. Nagios), great, it'll alert you if something breaks. If not, you'll have to test the services yourself every few packages. And don't forget to open a counter-ticket for someone to implement a monitoring solution, already. After a while, only important packages (apache, mysql, postfix...) will be left. Do those one at a time, and restart the services afterwards. Read the release notes first. Run revdep-rebuild. Check that the services work. Finally, you'll be left with the guaranteed-to-break updates like grub2 (50/50) and udev (100% you're fucked prepare for downtime). Grub2 can of course be skipped until the hardware dies. Best of luck to you with udev =)
Re: [gentoo-user] How to prevent a dns amplification attack
On 28-Mar-13 9:51, Norman Rieß 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? Try to set-up connection rate limiting using iptables... Jarry -- ___ This mailbox accepts e-mails only from selected mailing-lists! Everything else is considered to be spam and therefore deleted.
Re: [gentoo-user] Updating our live servers. I'm scared!
Hahahah udev hell!! I did go through that updating from 2.6 to 3.4. That was quite an experience But for kernel 3.* has udev not been phased out in our gentoo boxes? Will have to double check when I get back behind a console. N. On 3/28/13, Michael Orlitzky mich...@orlitzky.com wrote: On 03/28/2013 11:38 AM, Nick Khamis wrote: Hello Everyone, Just got a ticket assigned to me where we need to update our production servers. uname -a Linux noun 3.4.9-gentoo #2 SMP Sat Oct 13 09:35:07 EDT 2012 x86_64 Intel(R) Xeon(TM) CPU 3.60GHz GenuineIntel GNU/Linux eselect [18] hardened/linux/amd64 * I don't think they have been updated since the initial install and wanted to get a little feedback on some safe practices and methods that should be performed before and while doing so. This isn't that old, you'll be fine. First run an emerge --sync to update the tree. Then list everything it wants to upgrade: emerge -puDN1 world Once you have that list, go through a few at a time, updating non-essential packages. For example, emerge -u1 timezone-data man-pages ... Every once in a while, run a revdep-rebuild. If you have service monitoring (e.g. Nagios), great, it'll alert you if something breaks. If not, you'll have to test the services yourself every few packages. And don't forget to open a counter-ticket for someone to implement a monitoring solution, already. After a while, only important packages (apache, mysql, postfix...) will be left. Do those one at a time, and restart the services afterwards. Read the release notes first. Run revdep-rebuild. Check that the services work. Finally, you'll be left with the guaranteed-to-break updates like grub2 (50/50) and udev (100% you're fucked prepare for downtime). Grub2 can of course be skipped until the hardware dies. Best of luck to you with udev =)
Re: [gentoo-user] Updating our live servers. I'm scared!
On 03/28/2013 12:56 PM, Nick Khamis wrote: Hahahah udev hell!! I did go through that updating from 2.6 to 3.4. That was quite an experience But for kernel 3.* has udev not been phased out in our gentoo boxes? Will have to double check when I get back behind a console. I'm afraid not! Once you sync, you can do, eselect news read 23 to see the news item that was posted about it (title: 2013-01-23-udev-upgrade). Even that doesn't contain all of the information.. some of it is spread throughout bugs and across mailing list discussions. Oh and they decided to rename your NICs to owiu23awds89, which stands for, actually-nobody-knows-welcome24-to16-hell9-slot12-moon-phase-36-hey-if-you-enjoyed-this-give-systemd-a-try, or something like that. It's all explained very poorly in the cited links.
Re: [gentoo-user] Updating our live servers. I'm scared!
So basically, no long weekend for me here in Canada. Thanks a lot guys for your time.Wish me luck. Happy easter/holidays!!! N. On 3/28/13, Michael Orlitzky mich...@orlitzky.com wrote: On 03/28/2013 12:56 PM, Nick Khamis wrote: Hahahah udev hell!! I did go through that updating from 2.6 to 3.4. That was quite an experience But for kernel 3.* has udev not been phased out in our gentoo boxes? Will have to double check when I get back behind a console. I'm afraid not! Once you sync, you can do, eselect news read 23 to see the news item that was posted about it (title: 2013-01-23-udev-upgrade). Even that doesn't contain all of the information.. some of it is spread throughout bugs and across mailing list discussions. Oh and they decided to rename your NICs to owiu23awds89, which stands for, actually-nobody-knows-welcome24-to16-hell9-slot12-moon-phase-36-hey-if-you-enjoyed-this-give-systemd-a-try, or something like that. It's all explained very poorly in the cited links.
Re: [gentoo-user] Updating our live servers. I'm scared!
On 03/28/2013 01:16 PM, Nick Khamis wrote: So basically, no long weekend for me here in Canada. Thanks a lot guys for your time.Wish me luck. Happy easter/holidays!!! I'm being a bit dramatic. I would plan on spending ~4 hours researching, planning, and documenting the udev upgrade. Maybe an hour to execute it in the middle of the night, physically present. You can expect around 15 minutes downtime if all goes well. The rest of the updates you can do at your leisure, although the critical services should be restarted and checked during off-hours.
Re: [gentoo-user] Updating our live servers. I'm scared!
First hickup emerge -puDN1 world !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi' !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and We were always running hardened. Never changed the profile. N. On 3/28/13, Michael Orlitzky mich...@orlitzky.com wrote: On 03/28/2013 01:16 PM, Nick Khamis wrote: So basically, no long weekend for me here in Canada. Thanks a lot guys for your time.Wish me luck. Happy easter/holidays!!! I'm being a bit dramatic. I would plan on spending ~4 hours researching, planning, and documenting the udev upgrade. Maybe an hour to execute it in the middle of the night, physically present. You can expect around 15 minutes downtime if all goes well. The rest of the updates you can do at your leisure, although the critical services should be restarted and checked during off-hours.
Re: [gentoo-user] Updating our live servers. I'm scared!
On 03/28/2013 01:43 PM, Nick Khamis wrote: First hickup emerge -puDN1 world !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi' !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and We were always running hardened. Never changed the profile. Hmm.. this is probably /someone's/ bug. Nevertheless, all you have to do to fix it us update portage to the current stable version, which supports EAPI5. Can you switch to another profile temporarily and get portage updated?
Re: [gentoo-user] Updating our live servers. I'm scared!
On 28.03.2013 21:49, Michael Orlitzky wrote: On 03/28/2013 01:43 PM, Nick Khamis wrote: First hickup emerge -puDN1 world !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi' !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and We were always running hardened. Never changed the profile. Hmm.. this is probably /someone's/ bug. Nevertheless, all you have to do to fix it us update portage to the current stable version, which supports EAPI5. Can you switch to another profile temporarily and get portage updated? I guess this is related to the recent profile upgrade (as of 2013-02-10). In my $ eselect news list I get the last news item related to this upgrade. As it states, Everyone should upgrade as soon as possible (but please make sure sys-apps/portage is updated to current stable *before* you switch profile). this formally requires a new profile tree with EAPI=5. So, read the news item, emerge portage, then # eselect profile and you're done. -- Best wishes, Yuri K. Shatroff
Re: [gentoo-user] Updating our live servers. I'm scared!
I switched to the default profile from hardened: eselect profile list Available profile symlink targets: [1] default/linux/x86/13.0 * env-update !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/default/linux/x86/13.0/eapi' Regenerating /etc/ld.so.cache... And still can't update portage. N. On 3/28/13, Michael Orlitzky mich...@orlitzky.com wrote: On 03/28/2013 01:43 PM, Nick Khamis wrote: First hickup emerge -puDN1 world !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi' !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and We were always running hardened. Never changed the profile. Hmm.. this is probably /someone's/ bug. Nevertheless, all you have to do to fix it us update portage to the current stable version, which supports EAPI5. Can you switch to another profile temporarily and get portage updated?
Re: [gentoo-user] Updating our live servers. I'm scared!
But we never changed our profile? Always running hardened server. N. On 3/28/13, Nick Khamis sym...@gmail.com wrote: I switched to the default profile from hardened: eselect profile list Available profile symlink targets: [1] default/linux/x86/13.0 * env-update !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/default/linux/x86/13.0/eapi' Regenerating /etc/ld.so.cache... And still can't update portage. N. On 3/28/13, Michael Orlitzky mich...@orlitzky.com wrote: On 03/28/2013 01:43 PM, Nick Khamis wrote: First hickup emerge -puDN1 world !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi' !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and We were always running hardened. Never changed the profile. Hmm.. this is probably /someone's/ bug. Nevertheless, all you have to do to fix it us update portage to the current stable version, which supports EAPI5. Can you switch to another profile temporarily and get portage updated?
Re: [gentoo-user] Updating our live servers. I'm scared!
As mentioned earlier a temporary change of profile got me on my way eselect profile set 0 env-update eselect profile set 7 Moving forward... Thanks guys. On 3/28/13, Nick Khamis sym...@gmail.com wrote: But we never changed our profile? Always running hardened server. N. On 3/28/13, Nick Khamis sym...@gmail.com wrote: I switched to the default profile from hardened: eselect profile list Available profile symlink targets: [1] default/linux/x86/13.0 * env-update !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/default/linux/x86/13.0/eapi' Regenerating /etc/ld.so.cache... And still can't update portage. N. On 3/28/13, Michael Orlitzky mich...@orlitzky.com wrote: On 03/28/2013 01:43 PM, Nick Khamis wrote: First hickup emerge -puDN1 world !!! Unable to parse profile: '/etc/portage/make.profile' !!! ParseError: Profile contains unsupported EAPI '5': '/usr/portage/profiles/eapi-5-files/eapi' !!! Your current profile is invalid. If you have just changed your profile !!! configuration, you should revert back to the previous configuration. !!! Allowed actions are limited to --help, --info, --search, --sync, and We were always running hardened. Never changed the profile. Hmm.. this is probably /someone's/ bug. Nevertheless, all you have to do to fix it us update portage to the current stable version, which supports EAPI5. Can you switch to another profile temporarily and get portage updated?
Re: [gentoo-user] Updating our live servers. I'm scared!
Nick Khamis wrote: Hahahah udev hell!! I did go through that updating from 2.6 to 3.4. That was quite an experience But for kernel 3.* has udev not been phased out in our gentoo boxes? Will have to double check when I get back behind a console. N. Just a thought. Have you thought about switching to eudev? That would solve some udev issues. Since you are running a hardened profile and servers, may not be a option tho. 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 28.03.2013 16:38, schrieb Michael Mol: On 03/28/2013 04:51 AM, Norman Rieß 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? I'm not sure it can be done. You can't make a resolver available to everybody without somebody in that everybody group abusing it, and that's exacly what happens in a DNS amplification attack. Restrict your resolver to be accessible only to your network or, at most, those of the specific group of people you're seeking to help. You *might* try restricting the resolver to only respond to TCP requests rather than UDP requests, but if the resolver sends response data along with that first SYN+ACK, then nothing is solved, and you've opened yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver went offline as a result of a SYN flood, at least it wouldn't be part of an amplification attack any longer...) Thank you Michael!
Re: [gentoo-user] Updating our live servers. I'm scared!
Yeah these guys seem to think that our servers MUST run on the hardened profile... On 3/28/13, Dale rdalek1...@gmail.com wrote: Nick Khamis wrote: Hahahah udev hell!! I did go through that updating from 2.6 to 3.4. That was quite an experience But for kernel 3.* has udev not been phased out in our gentoo boxes? Will have to double check when I get back behind a console. N. Just a thought. Have you thought about switching to eudev? That would solve some udev issues. Since you are running a hardened profile and servers, may not be a option tho. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] abi_x86_32
On Thu, Mar 28, 2013 at 1:59 AM, Raffaele BELARDI raffaele.bela...@st.com wrote: I recently switched from no- to multilib. In yesterday's emerge I got tens of blockers due to conflict with emul-linux-x86-xlibs-20130224. I solved as suggested in http://forums.gentoo.org/viewtopic-t-953900.html?sid=f7a643eca8ec01540164578f372c374f and http://bugs.gentoo.org/461608 that is by adding abi_x86_32 to USE and unmasking emul-linux-x86-xlibs-20130224-r1, but didn't really understand what I was doing. Can anybody shed some light on this USE flag and what's going on with multilib? Old binary emul-linux* multilib packages are being replaced by a true compiled-from-source multilib solution. There are a few packages still need to be updated but it mostly works already. I think it will allow for more fine-grained dependencies as well for 32-bit apps on 64-bit systems. Like the forum post you linked says, instead of setting abi_x86_32 as a USE flag, what you can do in your make.conf is set: ABI_X86=64 32 (if you want to build both 32bit and 64bit) You may need to unmerge the emul-linux* packages manually then emerge deep world and figure out if you have any packages that have not yet been updated to the new way of doing things.
Re: [gentoo-user] Updating our live servers. I'm scared!
Nick Khamis wrote: Yeah these guys seem to think that our servers MUST run on the hardened profile... I just wanted to mention it in case its existence had slipped your mind. I know when the time came, I switched from udev to eudev and it has worked fine for my desktop. I plug in cameras, USB sticks, printers and other goodies which is likely something you don't do on a server. After reading about all the troubles others have had, I'm glad I switched. My network still has the same name and all too. Still crossing fingers tho. I just wasn't sure how compatible eudev would be with a hardened profile is all. Best of luck with the upgrade tho. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Best whois client?
On 27 March 2013, at 23:37, Michael Orlitzky wrote: ... Like Stroller I've been using net-misc/whois for ever and it does what I want, but don't know what the other packages may be able to do/do better. I would also be interested to find out why people prefer using these. They're all identical. The whois protocol is stupid simple The search I made before posting led me the wikipedia article which mentioned, for example, using thick and thin client models. http://en.wikipedia.org/wiki/Whois#Thin_and_thick_lookups One might assume, for example, that a thin client might tend to give more accurate and up-to-date information, but of course there's also the issue that the whois server for the domain might move. Thus the client might need to be updated in a timely manner, too. I have a Gentoo box here that, embarrassingly, hasn't been updated in several years. It seems to sometimes give different results than my laptop does. Stroller.
[gentoo-user] Re: abi_x86_32
On 28/03/13 20:39, Paul Hartman wrote: Like the forum post you linked says, instead of setting abi_x86_32 as a USE flag, what you can do in your make.conf is set: ABI_X86=64 32 (if you want to build both 32bit and 64bit) I think ABI_X86=32 is enough, since on AMD64 the 64 is always there implicitly.
Re: [gentoo-user] How to prevent a dns amplification attack
On 28/03/2013 17:38, Michael Mol wrote: On 03/28/2013 04:51 AM, Norman Rieß 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? I'm not sure it can be done. You can't make a resolver available to everybody without somebody in that everybody group abusing it, and that's exacly what happens in a DNS amplification attack. Restrict your resolver to be accessible only to your network or, at most, those of the specific group of people you're seeking to help. You *might* try restricting the resolver to only respond to TCP requests rather than UDP requests, NO NO NO NO NO Under no circumstances ever do this. The service breaks horribly when you do this and it has to work even remotely hard. Most likely your ISP will outright ban you for that if you use the ISP's caches. I knwo I do, and so does every other major ISP in this country. but if the resolver sends response data along with that first SYN+ACK, then nothing is solved, and you've opened yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver went offline as a result of a SYN flood, at least it wouldn't be part of an amplification attack any longer...) Or just use the ISP's DNS caches. In the vast majority of cases, the ISP knows how to do it right and the user does not. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Is 'MAKEOPTS=--jobs --load-average=5' silly?
On 28 March 2013, at 14:03, Peter Humphrey wrote: ... This box is an i5 with four single-threaded CPUs … Your usage of the term CPUs is making me twitch.
Re: [gentoo-user] How to prevent a dns amplification attack
On 03/28/2013 03:16 PM, Alan McKinnon wrote: On 28/03/2013 17:38, Michael Mol wrote: On 03/28/2013 04:51 AM, Norman Rieß 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? I'm not sure it can be done. You can't make a resolver available to everybody without somebody in that everybody group abusing it, and that's exacly what happens in a DNS amplification attack. Restrict your resolver to be accessible only to your network or, at most, those of the specific group of people you're seeking to help. You *might* try restricting the resolver to only respond to TCP requests rather than UDP requests, NO NO NO NO NO Under no circumstances ever do this. The service breaks horribly when you do this and it has to work even remotely hard. Most likely your ISP will outright ban you for that if you use the ISP's caches. I knwo I do, and so does every other major ISP in this country. Er, what? When we're talking about a recursive resolver requiring clients connecting to it to use TCP, what does upstream care? He's talking about running his own open DNS server. but if the resolver sends response data along with that first SYN+ACK, then nothing is solved, and you've opened yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver went offline as a result of a SYN flood, at least it wouldn't be part of an amplification attack any longer...) Or just use the ISP's DNS caches. In the vast majority of cases, the ISP knows how to do it right and the user does not. Generally true, though I've known people to choose not to use ISP caches owing to the ISP's implementation of things like '*' records, ISPs applying safety filters against some hostnames, and concerns about the persistence of ISP request logs. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] How to prevent a dns amplification attack
Le 28/03/2013 17:53, Jarry a écrit : On 28-Mar-13 9:51, Norman Rieß 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? Try to set-up connection rate limiting using iptables... Jarry Hi, a good example, in French but the commands will be sufficient : http://www.bortzmeyer.org/rate-limiting-dns-open-resolver.html Paul
Re: [gentoo-user] How to prevent a dns amplification attack
On 28/03/2013 21:38, Michael Mol wrote: On 03/28/2013 03:16 PM, Alan McKinnon wrote: On 28/03/2013 17:38, Michael Mol wrote: On 03/28/2013 04:51 AM, Norman Rieß 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? I'm not sure it can be done. You can't make a resolver available to everybody without somebody in that everybody group abusing it, and that's exacly what happens in a DNS amplification attack. Restrict your resolver to be accessible only to your network or, at most, those of the specific group of people you're seeking to help. You *might* try restricting the resolver to only respond to TCP requests rather than UDP requests, NO NO NO NO NO Under no circumstances ever do this. The service breaks horribly when you do this and it has to work even remotely hard. Most likely your ISP will outright ban you for that if you use the ISP's caches. I knwo I do, and so does every other major ISP in this country. Er, what? When we're talking about a recursive resolver requiring clients connecting to it to use TCP, what does upstream care? He's talking about running his own open DNS server. Because the list is indexed and archived and Googled forever. Others may get the idea that TCP-only DNS caches are a good idea in general. Have you ever had to deal with the insanity caused when Windows Servers insist on using TCP only, and YOU are the upstream? I understand what the OP was suggesting, but he did not limit the usefulness and scope of the suggestion, so I did. but if the resolver sends response data along with that first SYN+ACK, then nothing is solved, and you've opened yourself up to a SYN flood-based DoS attack. (OTOH, if your resolver went offline as a result of a SYN flood, at least it wouldn't be part of an amplification attack any longer...) Or just use the ISP's DNS caches. In the vast majority of cases, the ISP knows how to do it right and the user does not. Generally true, though I've known people to choose not to use ISP caches owing to the ISP's implementation of things like '*' records, ISPs applying safety filters against some hostnames, and concerns about the persistence of ISP request logs. I get a few of those too every now and again. I know for sure in my case their fears are unfounded, but can't prove it. Those few (and they are few) can go ahead and deploy their own cache. I can't stop them, they are free to do it, they are also free to ignore my advice of they choose. -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] How to prevent a dns amplification attack
On Thu, 28 Mar 2013 16:12:04 +0100 Volker Armin Hemmann volkerar...@googlemail.com 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? I haven't looked into it but. You could perhaps reduce the amplification by looking for trends that maximise response sizes such as the 100x amp against spamhaus of late, but you would be fighting against the wind and only buying time. Rate limiting may work but bear in mind that so many servers could be used that attacks maybe ongoing and you wouldn't notice, again you may be able to make attackers need to be subtler or go to more effort like for spam but you are not going to eradicate it. Really you would need some sort of network of dns servers communicating about who they are hurting as thankfully there is often a single victim, but really it would be better if the IETF had listened to the dangers and even now simply redesigned DNSSEC. As for tcp I used to have all my OpenBSD clients resolvers using the tcp option in resolv.conf but I haven't noticed another OS's resolver with that option. There are decent protections against syn floods but I assume you are wanting random clients to connect.
Re: [gentoo-user] How to prevent a dns amplification attack
On Thu, Mar 28, 2013 at 3:02 PM, Alan McKinnon alan.mckin...@gmail.com wrote: Or just use the ISP's DNS caches. In the vast majority of cases, the ISP knows how to do it right and the user does not. Generally true, though I've known people to choose not to use ISP caches owing to the ISP's implementation of things like '*' records, ISPs applying safety filters against some hostnames, and concerns about the persistence of ISP request logs. I get a few of those too every now and again. I know for sure in my case their fears are unfounded, but can't prove it. Those few (and they are few) can go ahead and deploy their own cache. I can't stop them, they are free to do it, they are also free to ignore my advice of they choose. In my case, my ISP's DNS servers are slow (several seconds to reply), fail randomly when they should resolve, return an IP (which goes to their ad-laden helper website if you are using a web browser) when they should instead return nxdomain, and they have openly admitted to selling customer DNS lookup history to marketers for targeted advertising. Thanks for being one of the good guys. :)
[gentoo-user] Re: user folder in path when mounting
I've been mounting my external HD in thunar. When I clicked the device icon, the HD was mounted to /media/VOLUME_LABEL/. Now I see the path has changed to /run/media/grant/VOLUME_LABEL/ and the grant folder is: drwxr-x---+ 3 root root which I think is preventing my automated remote backups from working because the backup user's home directory which contains authorized_keys is on the backup HD. What is the right way to get this working again? - Grant I was able to get this working by defining a label for the HD with e2label and adding it to /etc/fstab like so: LABEL=backup/mnt/backup ext3 defaults,noauto,noatime 0 2 - Grant
Re: [gentoo-user] How to prevent a dns amplification attack
listened to the dangers and even now simply redesigned DNSSEC. Or they could fudge it by making every request requiring padding larger than the response. Bandwidth would increase astronomically but amp attacks would have to find other avenues.
Re: [gentoo-user] How to prevent a dns amplification attack
On 03/28/2013 04:53 PM, Paul Hartman wrote: On Thu, Mar 28, 2013 at 3:02 PM, Alan McKinnon alan.mckin...@gmail.com wrote: Or just use the ISP's DNS caches. In the vast majority of cases, the ISP knows how to do it right and the user does not. Generally true, though I've known people to choose not to use ISP caches owing to the ISP's implementation of things like '*' records, ISPs applying safety filters against some hostnames, and concerns about the persistence of ISP request logs. I get a few of those too every now and again. I know for sure in my case their fears are unfounded, but can't prove it. Those few (and they are few) can go ahead and deploy their own cache. I can't stop them, they are free to do it, they are also free to ignore my advice of they choose. In my case, my ISP's DNS servers are slow (several seconds to reply), fail randomly when they should resolve, return an IP (which goes to their ad-laden helper website if you are using a web browser) when they should instead return nxdomain, and they have openly admitted to selling customer DNS lookup history to marketers for targeted advertising. Wow. That's...all the fail. Thanks for being one of the good guys. :) Indeed. signature.asc Description: OpenPGP digital signature
Re: [gentoo-user] How to prevent a dns amplification attack
On 03/28/2013 04:57 PM, Kevin Chadwick wrote: listened to the dangers and even now simply redesigned DNSSEC. Or they could fudge it by making every request requiring padding larger than the response. Bandwidth would increase astronomically but amp attacks would have to find other avenues. Infeasible; the requester cannot know the size of the response in advance. If a packet comes in, and the response is larger than the request, is it really an amp packet, did the client not know, or is the server misconfigured and not limiting the response data as much as it could? signature.asc Description: OpenPGP digital signature
[gentoo-user] Re: cyrus-sasl necessary with localhost webmail?
I recently switched from Thunderbird to Roundcube (highly recommended), switched to the non-SSL courier daemon, and plugged the firewall hole since courier resides on the same system as my web server. Do I still need cyrus-sasl or will a webmail client authenticate directly with courier? I have authmodulelist=authshadow in /etc/courier/authlib/authdaemonrc. - Grant Can anyone tell me if it's necessary to run cyrus-sasl between courier and a webmail client if they're on the same machine? - Grant
Re: [gentoo-user] How to prevent a dns amplification attack
Am 28.03.2013 10:07, schrieb Adam Carter: Why are you making your server available to everyone? For the lulz mostly.
Re: [gentoo-user] How to prevent a dns amplification attack
On Thu, 28 Mar 2013 17:04:25 -0400 Michael Mol mike...@gmail.com wrote: listened to the dangers and even now simply redesigned DNSSEC. Or they could fudge it by making every request requiring padding larger than the response. Bandwidth would increase astronomically but amp attacks would have to find other avenues. Infeasible; the requester cannot know the size of the response in advance. If a packet comes in, and the response is larger than the request, is it really an amp packet, did the client not know, or is the server misconfigured and not limiting the response data as much as it could? I'm certainly not saying it's a good idea, hence the 'fudge' and 'making every request' which would mean non updateable clients or non updated routers (90%) needing special treatment. I'm sure there are probably other hurdles to it but it is certainly possible to make a request much larger than any potential response similar to the anti-spam system that makes creating a message take a lot of cpu and then only accepting messages from those that do (hsomething I think, only works too if all take part but would eliminate spam almost completely). However thinking about it, considering the want for dns to provide larger things like encryption keys, huge requests may be the best long term solution for a DNSSEC which seemingly refuses out of pride to add something like DNSCURVE to prevent spoofing. Similar to firewalls only sending a single syn ack (less than or equalise)
Re: [gentoo-user] Best whois client?
On 03/28/2013 03:11 PM, Stroller wrote: The search I made before posting led me the wikipedia article which mentioned, for example, using thick and thin client models. http://en.wikipedia.org/wiki/Whois#Thin_and_thick_lookups One might assume, for example, that a thin client might tend to give more accurate and up-to-date information, but of course there's also the issue that the whois server for the domain might move. Thus the client might need to be updated in a timely manner, too. The thin model sort of works like DNS, except everything is unstructured and totally made-up on the server side and guessed-at on the client side. The clients are trying to parse the unstructured output, like you would if you were trying to screen scrape a webpage. As of ten seconds ago, this is what I get for a lookup of orlitzky.com: Domain Name: ORLITZKY.COM Registrar: GANDI SAS Whois Server: whois.gandi.net Referral URL: http://www.gandi.net ... The Whois Server: for the domain is something like an NS record, where the guy higher up points you at the next level down. If the whois server for the domain changed, you wouldn't need to update the client -- you could just ask the top-level server for it again. What *would* make you update the client is if, say, that top-level server started outputting a space between Server and :.
Re: [gentoo-user] Is 'MAKEOPTS=--jobs --load-average=5' silly?
On Thursday 28 March 2013 19:28:47 Stroller wrote: On 28 March 2013, at 14:03, Peter Humphrey wrote: ... This box is an i5 with four single-threaded CPUs … Your usage of the term CPUs is making me twitch. What would you have said? And it wasn't usage, it was use. -- Peter
Re: [gentoo-user] How to prevent a dns amplification attack
On Thursday 28 March 2013 20:53:49 Paul Hartman wrote: In my case, my ISP's DNS servers are slow (several seconds to reply), fail randomly when they should resolve, return an IP (which goes to their ad-laden helper website if you are using a web browser) when they should instead return nxdomain, and they have openly admitted to selling customer DNS lookup history to marketers for targeted advertising. That is just evil. Have you no alternative to this ISP? -- Peter
Re: [gentoo-user] Is 'MAKEOPTS=--jobs --load-average=5' silly?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 29/03/13 00:40, Peter Humphrey wrote: On Thursday 28 March 2013 19:28:47 Stroller wrote: On 28 March 2013, at 14:03, Peter Humphrey wrote: ... This box is an i5 with four single-threaded CPUs … Your usage of the term CPUs is making me twitch. What would you have said? And it wasn't usage, it was use. I can only imagine he was pointing out that you have a single CPU with four cores in it. - -- Mateusz K. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) iQIcBAEBAgAGBQJRVO1fAAoJEM1mucMq2pqXaS8QAKPfQ72PlpiAKdf2xKmXKOnU 3sH2108QfVWxo3Aw+aQlUwSXukkwwJY7vZWRXHsYyU58A03UmBx2rQnYD+cXeUlN pm2HcIyp5qypX2oISK7i8Xg38Op/MCedtVU24uOZLYsQ9YUrBuHOhbKTmI5PvpAP hmNRbUFx+pdYtLJsvR11L+kgNXC/T8ZIyw3vouktEidf7igRXVs5oCZyaCLfxDXk XT8V1HHxbvU7Y5kUKoVAuWAHtxKqnVCyqpz/G1gLsSVrksfP4Spv+7qWe87yiBdu fd8CBlc6A6cArz82owim9YdllKMa2T6/ohptOkLyrWhU7Q4piGD48ky55dqlYzB6 Zsa6DuiUEmIYfWTviR1pXgFsMTCpkmj2mLSZ5xLL45/I1U2+9NsbiKxnwe/8GfpU oUY2owjkpfxoaOyWZ0YCBgXEIuWpzJllifv5B18XroC9QSWPCckhOoR9JnrfS6QW 1EVsomK5moJ/Qqe4Xtx0XZj8fUmOnelV2h/NoNRt0kdQFacT8+y6xTGCdOb+FLxf e8qUUtOiEv5zSbHO1cHuqzmHdXcr7euZI881Vp9nFbdvbmXD3hrQybakdVzq9gt/ cRg+JvE4pGyUBtNdVy8vWW4PWf7rw0gOqF3PpuJB2siFqSZs0fYREIzRFucVFj5/ EWl9A8gv/BAZv6D6S4/L =2eKx -END PGP SIGNATURE-
Re: [gentoo-user] Is 'MAKEOPTS=--jobs --load-average=5' silly?
On Friday 29 March 2013 01:24:48 Mateusz Kowalczyk wrote: I can only imagine he was pointing out that you have a single CPU with four cores in it. You're right, of course. I should have said /cores/. -- Peter
[gentoo-user] emul-linux-x86-libs blocking tons of X libs
I've been experiencing this issue whenever I tried to update in the
fairly recent weeks/days. ‘emerge -avutND’ produces a long list of
packages (see attachment) and then fails due to a block.
[blocks B ] =app-emulation/emul-linux-x86-xlibs-20130224
(=app-emulation/emul-linux-x86-xlibs-20130224 is blocking
x11-libs/libXdmcp-1.1.1-r1, x11-libs/libXtst-1.2.1-r1,
x11-libs/libXt-1.1.3-r1, x11-proto/renderproto-0.11.1-r1,
x11-libs/libXext-1.3.1-r1, x11-libs/libXcomposite-0.4.4-r1,
x11-libs/libXxf86vm-1.1.2-r1, x11-libs/libXpm-3.5.10-r1,
media-libs/fontconfig-2.10.2-r1, x11-proto/inputproto-2.3,
x11-libs/libXdamage-1.1.4-r1, x11-proto/xf86bigfontproto-1.2.0-r1,
x11-libs/libXaw-1.0.11-r2, x11-libs/libICE-1.0.8-r1,
x11-proto/xproto-7.0.23-r2, x11-libs/libX11-1.5.0-r1,
x11-libs/libXi-1.7, x11-libs/libXrender-0.9.7-r1,
x11-libs/libXmu-1.1.1-r1, media-libs/freetype-2.4.11-r2,
x11-proto/damageproto-1.2.1-r1, x11-proto/recordproto-1.14.2-r1,
x11-libs/libXfixes-5.0-r1, x11-libs/libXrandr-1.4.0-r1,
x11-proto/xf86vidmodeproto-2.3.1-r1, x11-proto/kbproto-1.0.6-r1,
x11-libs/libXau-1.0.7-r1, x11-proto/compositeproto-0.4.2-r1,
dev-libs/libpthread-stubs-0.3-r1, x11-proto/xcb-proto-1.8-r2,
x11-proto/randrproto-1.4.0-r1, x11-proto/fixesproto-5.0-r1,
x11-libs/libpciaccess-0.13.1-r1, x11-libs/libXcursor-1.1.13-r1,
x11-libs/libxcb-1.9-r1, x11-proto/xextproto-7.2.1-r1,
x11-libs/libSM-1.2.1-r1, x11-libs/libXft-2.3.1-r1)
Usually I'd unmerge one of the packages in question if I deem that I
don't need them but I'm unsure as to what the package actually does
nor what do the packages that it's blocking exactly do. Googling
around for the package name doesn't give much information.
Any suggestions as to how I could go about resolving this particular
block?
Quick ‘equery’ shows only a few things that depend on it:
✓ ShanaX61s shana % equery d emul-linux-x86-gtklibs
% [P ~ ] [J 0 ]
[L 38 ]
* These packages depend on emul-linux-x86-gtklibs:
dev-util/android-sdk-update-manager-21 (amd64 ?
app-emulation/emul-linux-x86-gtklibs)
sys-devel/gcc-4.5.4 (multilib ? app-emulation/emul-linux-x86-gtklibs)
sys-devel/gcc-4.6.3 (multilib ? app-emulation/emul-linux-x86-gtklibs)
sys-devel/gcc-4.7.2-r1 (multilib ? app-emulation/emul-linux-x86-gtklibs)
I have neither ‘amd64’ nor ‘multilib’ set which raises the question of
how and why it got onto my system in the first place… I'm still
somewhat wary of clobbering something that has ‘gcc’ in its depgraph…
--
Mateusz K.
[nomerge ] app-shells/zsh-5.0.2 USE=gdbm pcre unicode -caps -debug -doc
-examples -maildir -static
[ebuild U ] sys-apps/groff-1.22.2 [1.22.1] USE=X -examples LINGUAS=ja
3,978 kB
[ebuild U ] sys-fs/udev-198-r6 [197-r9] USE=acl gudev hwdb introspection
keymap kmod openrc -doc (-selinux) -static-libs 2,094 kB
[nomerge ] dev-lang/python-2.7.3-r3:2.7 USE=gdbm ipv6 ncurses readline
sqlite ssl threads tk (wide-unicode) xml -berkdb -build -doc -examples
-hardened% -wininst
[ebuild U ] app-admin/python-updater-0.11 [0.10-r2] 10 kB
[ebuild U ] x11-libs/gtk+-2.24.17:2 [2.24.16:2] USE=cups introspection
(-aqua) -debug -examples {-test} -vim-syntax -xinerama 12,978 kB
[nomerge ] app-emacs/jde-2.4.1_pre20110622 USE=-doc -source
[nomerge ] dev-util/checkstyle-5.5 USE=-doc -source {-test}
[nomerge ] dev-java/guava-07 USE=-doc -source
[nomerge ]java-virtuals/jdk-with-com-sun-2011
[nomerge ] dev-java/icedtea-bin-7.2.3.6:7 USE=X cjk cups nsplugin
-alsa -doc -examples -source
[nomerge ] net-print/cups-1.6.2 [1.6.1] USE=X acl dbus filters
gnutls pam python ssl threads usb -avahi -debug -java -kerberos (-selinux)
-static-libs -systemd -xinetd -zeroconf LINGUAS=ja -ca -es -fr% -ru%
[nomerge ] net-print/foomatic-filters-4.0.17 USE=cups dbus
[ebuild U ]net-print/cups-filters-1.0.30 [1.0.29-r1] USE=jpeg
perl png tiff -avahi -static-libs 991 kB
[ebuild U ] net-print/cups-1.6.2 [1.6.1] USE=X acl dbus filters
gnutls pam python ssl threads usb -avahi -debug -java -kerberos (-selinux)
-static-libs -systemd -xinetd -zeroconf LINGUAS=ja -ca -es -fr% -ru% 8,168 kB
[ebuild U ] app-text/poppler-0.22.2-r2:0/35 [0.20.5:0/0]
USE=cairo cjk curl cxx introspection jpeg lcms png tiff utils -debug -doc
-jpeg2k -qt4 2,164 kB
[nomerge ] app-editors/emacs-24.3:24 USE=X dbus gif gnutls gpm gtk gtk3
jpeg m17n-lib png svg tiff xft xpm -Xaw3d -alsa (-aqua) -athena -games -gconf
-gsettings -gzip-el -hesiod -imagemagick -kerberos -libxml2 -livecd -motif
-pax_kernel (-selinux) -sound -source -toolkit-scroll-bars -wide-int
[nomerge ] dev-libs/m17n-lib-1.6.4 USE=X anthy gd
Re: [gentoo-user] Is 'MAKEOPTS=--jobs --load-average=5' silly?
On Fri, Mar 29, 2013 at 7:29 AM, Peter Humphrey pe...@humphrey.ukfsn.org wrote: On Friday 29 March 2013 01:24:48 Mateusz Kowalczyk wrote: I can only imagine he was pointing out that you have a single CPU with four cores in it. You're right, of course. I should have said /cores/. -- Peter Cores or CPUs.. in this context it's *almost*, __NOT EXACTLY__ same. -- Nilesh Govindrajan http://nileshgr.com
