Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?
Am 10.10.2013 16:38, schrieb Stefan G. Weichinger: I don't plan to stay with 3.8.13, this is just an intermediate step to get a working config. For now I don't have any more lost hpet interrupts etc and the LAN speed is fine. Emerging packages as well ... From this config I will then try 3.10.7-r1 again. Went back to 3.10.7-r1 yesterday ... performance fine so far. Today I checked back and found the following in dmesg. Should I disable some option? Thanks for any feedback, Stefan [20788.258330] NMI backtrace for cpu 16 [20788.258334] CPU: 16 PID: 0 Comm: swapper/16 Not tainted 3.10.7-gentoo-r1 #1 [20788.258336] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/10/2012 [20788.258338] task: 88042dcc9fe0 ti: 88042dcd6000 task.ti: 88042dcd6000 [20788.258340] RIP: 0010:[a0006e31] [a0006e31] acpi_idle_enter_simple+0x9e/0xde [processor] [20788.258346] RSP: 0018:88042dcd7e78 EFLAGS: 0093 [20788.258348] RAX: 12e824917a00 RBX: 880c2d1c78a0 RCX: b6e8 [20788.258350] RDX: 0ff9 RSI: 88082fc8 RDI: b6e0 [20788.258352] RBP: 0002 R08: R09: 0192 [20788.258354] R10: 0001 R11: R12: 880c2d1c7800 [20788.258356] R13: 12e605db654b R14: a00087d8 R15: [20788.258358] FS: 7fcbeb7de700() GS:88082fc8() knlGS:f77556c0 [20788.258360] CS: 0010 DS: ES: CR0: 8005003b [20788.258362] CR2: 7fd4098d2000 CR3: 00042d3a4000 CR4: 000407a0 [20788.258364] DR0: 00a0 DR1: DR2: 0003 [20788.258365] DR3: 00b0 DR6: 0ff0 DR7: 0400 [20788.258367] Stack: [20788.258368] 88102ccd4c00 a0008710 0002 8140284b [20788.258371] 01f6 81403b11 [20788.258374] 88102ccd4c00 0002 a0008710 88042dcd7fd8 [20788.258378] Call Trace: [20788.258382] [8140284b] ? cpuidle_enter_state+0x4b/0xe0 [20788.258386] [81403b11] ? ladder_select_state+0x31/0x1e0 [20788.258390] [8140297a] ? cpuidle_idle_call+0x9a/0x140 [20788.258394] [8103b919] ? arch_cpu_idle+0x9/0x30 [20788.258398] [81095439] ? cpu_startup_entry+0x59/0x130 [20788.258399] Code: 01 03 75 02 0f 09 e8 1f 50 08 e1 8a 43 08 3c 01 75 0a 48 89 df e8 c0 78 04 e1 eb 17 3c 02 75 07 e8 0f f9 ff ff eb 0c 8b 53 04 ec 48 8b 15 4c e0 81 e1 ed 31 ff e8 90 50 08 e1 80 7b 08 01 74 10 [20788.258440] NMI backtrace for cpu 20 [20788.258444] CPU: 20 PID: 0 Comm: swapper/20 Not tainted 3.10.7-gentoo-r1 #1 [20788.258445] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/10/2012 [20788.258447] task: 88042dccb960 ti: 88042dcde000 task.ti: 88042dcde000 [20788.258449] RIP: 0010:[a0006e31] [a0006e31] acpi_idle_enter_simple+0x9e/0xde [processor] [20788.258456] RSP: 0018:88042dcdfe78 EFLAGS: 0093 [20788.258457] RAX: 12e824919a00 RBX: 880c2d1c50a0 RCX: b6e8 [20788.258459] RDX: 0ff9 RSI: 88082fd0 RDI: b6e0 [20788.258461] RBP: 0002 R08: R09: 0193 [20788.258463] R10: 0001 R11: R12: 880c2d1c5000 [20788.258464] R13: 12e605db857d R14: a00087d8 R15: [20788.258467] FS: 7fcbeb7de700() GS:88082fd0() knlGS:f778d700 [20788.258469] CS: 0010 DS: ES: CR0: 8005003b [20788.258471] CR2: 7fd4098d2000 CR3: 00042d3a4000 CR4: 000407a0 [20788.258473] DR0: 00a0 DR1: DR2: 0003 [20788.258474] DR3: 00b0 DR6: 0ff0 DR7: 0400 [20788.258476] Stack: [20788.258477] 880c2d9e0400 a0008710 0002 8140284b [20788.258480] 01f7 81403b11 [20788.258484] 880c2d9e0400 0002 a0008710 88042dcdffd8 [20788.258487] Call Trace: [20788.258491] [8140284b] ? cpuidle_enter_state+0x4b/0xe0 [20788.258495] [81403b11] ? ladder_select_state+0x31/0x1e0 [20788.258498] [8140297a] ? cpuidle_idle_call+0x9a/0x140 [20788.258502] [8103b919] ? arch_cpu_idle+0x9/0x30 [20788.258506] [81095439] ? cpu_startup_entry+0x59/0x130 [20788.258508] Code: 01 03 75 02 0f 09 e8 1f 50 08 e1 8a 43 08 3c 01 75 0a 48 89 df e8 c0 78 04 e1 eb 17 3c 02 75 07 e8 0f f9 ff ff eb 0c 8b 53 04 ec 48 8b 15 4c e0 81 e1 ed 31 ff e8 90 50 08 e1 80 7b 08 01 74 10
OT - RAM disks - WAS Re: [gentoo-user] Network failed and weird error message
On 2013-10-13 5:49 PM, Dale rdalek1...@gmail.com wrote: Talk about putting some stuff on tmpfs. O_O I have always wanted to copy the tree to tmpfs and run time emerge -uvaDN world. Just to see how fast it will go. lol I remember once I worked for an Apple reseller that had this accounting program that required them to do some kind of 'reconciliation' every month that required a massive amount of processing - it took like 36 hours or something ridiculous (literally almost took all weekend), and he had implemented a rule that someone had to be there the entire time to baby sit the process - apparently it wasn't uncommon for there to be an error that would require them to restart it - and this was on a pretty powerful system at the time. Well, one weekend, when we were building a system for a customer with tons of RAM (for the time) I talked them into a little experiment. The boss didn't believe me when I told him I could get the reconciliation processing time down to less than a day (I told him probably just a few hours, but wasn't sure)... so we made a bet. I took a Quadra 900 (or maybe it was a 950), and added a bunch of RAM - I think we got it up to 128MB or something ridiculous (this was in about 1992). The accounting DB was about 40MB at the time, but hey, we had the RAM, so I just loaded it up. I created a RAM disk, copied the entire Accounting DB into it, and started running the reconciliation. The process finished after about 45 minutes (I was even surprised at that), and while there were no errors and it said it had completed successfully, the boss was sure that something had gone wrong. So, he re-ran it the old way on the old server, and almost 2 days later, when the numbers matched, he just shook his head and paid me off, muttering about the lost weekends over the last 5 years he'd been there. He kept that machine around for running the reconciliation for at least a few months, but then I left, so no idea how long he kept it for...
[gentoo-user] Re: scripted iptables-restore
Michael Orlitzky mich...@orlitzky.com wrote: Port knocking is cute, but imparts no extra security. It does, for instance if you use it to protect sshd and sshd turns out to be vulnerable; remember e.g. the security disaster with Debian. A better, secure way to achieve the same goal is with OpenVPN. Using yet another service with possible holes to protect a sshd? In this case, I would like port knocking at least for this OpenVPN. In this case, the absolute worst that could happen is that an attacker gains access to every open port on your system. While this is bad, it's not a clever new vulnerability: it's all of the old ones that were already there. It is exactly the kind of attacks for which one usually uses iptables. You are right, iptables is just one extra step of security, so the worst thing which can happen is that this step is useless. However, if you are willing to risk this only because of your own lazyness in scripting then why do you setup iptables in the first place? If there are insecure daemons listening on public addresses The problem is that nobody can be sure that some daemon is safe. Even presumably safe services turn out to be victims of new kind of attacks, occassionally.
[gentoo-user] Re: scripted iptables-restore (was: Where to put advanced routing configuration?)
Pandu Poluan pa...@poluan.info wrote: Thanks, Martin! I was about to create my own preprocessor, but I'll check out yours first. If it's what I had planned, may I contribute, too? Sure, patches are welcome.
[gentoo-user] Re: scripted iptables-restore
William Kenworthy bi...@iinet.net.au wrote: If you are going to go to this bother ... why not use shorewall, create When I checked for scripts creating rules, none fulfilled my needs. (I do not know whether I checked shorewall at this time). For instance, instead of dropping most packets, I want to reject them properly, only with a rate-limit to avoid DOS. Then there is the mentioned port knocking, some forwarding etc. pp. a custom configuration for each site (including any changes to services) and and have your script just copy them in and restart the various services including shorewall? Instead of managing dozens of configurations manually, I think it is easier to have one script which creates an appropriate custom configuration on all my machines, depending on certain files in /etc and other tests. That's why I always run my firewall script on startup (or if I severely change the configuration). I use a simple script with autosetup using network-manager network-manager is on my university's laptop (with Ubuntu - not my decision), but on any safe machine (running Gentoo) I refuse to install the gaping security hole polkit which unfortunately is a hard dependency of network-manager. As soon as polkit is on an machine on which you use a browser, it makes no sense to spend time pretending to make it secure: Barring your back door even more when the front door of your house was removed is rather pointless...
Re: OT - RAM disks - WAS Re: [gentoo-user] Network failed and weird error message
Tanstaafl wrote: On 2013-10-13 5:49 PM, Dale rdalek1...@gmail.com wrote: Talk about putting some stuff on tmpfs. O_O I have always wanted to copy the tree to tmpfs and run time emerge -uvaDN world. Just to see how fast it will go. lol I remember once I worked for an Apple reseller that had this accounting program that required them to do some kind of 'reconciliation' every month that required a massive amount of processing - it took like 36 hours or something ridiculous (literally almost took all weekend), and he had implemented a rule that someone had to be there the entire time to baby sit the process - apparently it wasn't uncommon for there to be an error that would require them to restart it - and this was on a pretty powerful system at the time. Well, one weekend, when we were building a system for a customer with tons of RAM (for the time) I talked them into a little experiment. The boss didn't believe me when I told him I could get the reconciliation processing time down to less than a day (I told him probably just a few hours, but wasn't sure)... so we made a bet. I took a Quadra 900 (or maybe it was a 950), and added a bunch of RAM - I think we got it up to 128MB or something ridiculous (this was in about 1992). The accounting DB was about 40MB at the time, but hey, we had the RAM, so I just loaded it up. I created a RAM disk, copied the entire Accounting DB into it, and started running the reconciliation. The process finished after about 45 minutes (I was even surprised at that), and while there were no errors and it said it had completed successfully, the boss was sure that something had gone wrong. So, he re-ran it the old way on the old server, and almost 2 days later, when the numbers matched, he just shook his head and paid me off, muttering about the lost weekends over the last 5 years he'd been there. He kept that machine around for running the reconciliation for at least a few months, but then I left, so no idea how long he kept it for... I remember those days. I quit my computer job just about a year or so before that. I think it was when I got tired of windoze 3.1 reinstalls. That model number sounds familiar to for some reason. ;-) I ordered the mobo. I'm worried that something could happen to this thing and me not have a rig at all. That ain't good. Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Network failed and weird error message
On Sunday 13 Oct 2013 22:49:41 Dale wrote: I don't overclock so I'm not worried about that. I did it once with a old Abit mobo with a AMD 2500+ CPU but it just didn't make much difference. O/C = higher costs. You need higher frequency memory, bigger CPU/case coolers and potentially a bigger PSU. If your budget is constrained then buy memory/cooler/PSU that will run with default settings. The 10% performance improvement that a modern CPU may give you when O/C is not really worth the hassle. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Gnat Compile Error
Hello, On Sun, 13 Oct 2013 17:32:29 +0200 Frank Steinmetzger war...@gmx.de wrote: You want to install gnat-gcc for a gcc version you don't have. You have gcc 4.6.3 and 4.7.3 installed (with 4.6.3 active). Unfortunately, my eix doesn't report me any gnat-gcc newer than 4.5. So I'm not sure how to proceed here apart from installing gcc-4.5.4, which is still in portage, but then of course you only have gnat in that old version. But 4.6.3 or 4.7.3 i have not in Portage. [15:07:57][ Akku: 99% ][siefke@gentoomobile:/usr/portage/dev-lang/gnat-gcc]$ ls ChangeLog gnat-gcc-4.2.3.ebuild gnat-gcc-4.4.7.ebuild Manifest gnat-gcc-4.3.5.ebuild gnat-gcc-4.5.4.ebuild files gnat-gcc-4.3.6.ebuild metadata.xml gnat-gcc-3.4.6.ebuild gnat-gcc-4.4.3.ebuild gnat-gcc-4.1.2.ebuild gnat-gcc-4.4.5.ebuild Give Alternatives? Thank you Regards Silvio Thank you Greetings Silvio
Re: [gentoo-user] Re: scripted iptables-restore
On 14/10/13 20:08, Martin Vaeth wrote: William Kenworthy bi...@iinet.net.au wrote: If you are going to go to this bother ... why not use shorewall, create When I checked for scripts creating rules, none fulfilled my needs. (I do not know whether I checked shorewall at this time). For instance, instead of dropping most packets, I want to reject them properly, only with a rate-limit to avoid DOS. Then there is the mentioned port knocking, some forwarding etc. pp. a custom configuration for each site (including any changes to services) and and have your script just copy them in and restart the various services including shorewall? Instead of managing dozens of configurations manually, I think it is easier to have one script which creates an appropriate custom configuration on all my machines, depending on certain files in /etc and other tests. That's why I always run my firewall script on startup (or if I severely change the configuration). Been there, done that, after the various disasters of editing/sed'iting in place config files I took the cowards way out - at least when it all goes wrong its now easy to fix, and is a LOT less fragile, especially after upgrades :) Its also a lot harder to do once you get to some of the weirder environments with conflicting requirements. Keep in mind that shorewall or similar wont handle all the parts needed to make this work ... vpn's, services etc will need scripting as well, but they certainly make the firewall part easier and more secure. Also, if you are editing iptables scripts yourself have a look at shorewall, monmotha or most other professional scripts - can you guarantee you are covering as many bases as these do? - I always shudder when I see someone put together a few rules and think its as good as something thats stood the test of time and review. Or think of it this way, you are using port knocking and trying for extreme defence in depth, but use a home brew firewall ... I dont see anything strange about your requirements and think they should be within the capability of most firewall setups and a knowledgeable admin. I totally agree on network manager - its a pita. In this cae its a left over from an abortive attempt to like gnome3 ... I am now using LXDE but everytime I try and strip more gnome out of the system it either breaks or reinstalls the gnomey bits Ive just removed :( Maybe a reinstall during the Christmas break - prezzies! BillK
Re: [gentoo-user] Re: scripted iptables-restore
On 10/14/2013 07:49 AM, Martin Vaeth wrote: Michael Orlitzky mich...@orlitzky.com wrote: Port knocking is cute, but imparts no extra security. It does, for instance if you use it to protect sshd and sshd turns out to be vulnerable; remember e.g. the security disaster with Debian. A better, secure way to achieve the same goal is with OpenVPN. Using yet another service with possible holes to protect a sshd? In this case, I would like port knocking at least for this OpenVPN. The sensitive parts of OpenVPN are audited regularly, and it uses SSL -- public key auth to exchange a symmetric key, both of which use tried-and-true algorithms/code. Port knocking on the other hand is just security through obscurity, and is visible over the wire (or over the air, most likely, if you're on a laptop). Obscurity does provide some benefit, but it gets dismissed because we tend to ignore the constant factor when talking about these things. A problem is solved if it's easy to exponentially increase the amount of work an attacker has to do. For an analogy, a somewhat-related issue is that of salting passwords. Typically one stores the salt in the database in clear text, and this tends to freak people out. Doesn't that make it easier for an attacker to brute force your passwords? Well, yes, but the salt isn't meant to stop a brute force attack. It's meant to stop rainbow table attacks. The way you stop brute force attacks is to use an algorithm with a variable number of rounds that can slow itself down (see: bcrypt). Hiding the salt would just be security through obscurity. You always assume that the attacker knows the details of your algorithm, including the constants. So while hiding the salt would make it a tiny bit harder to brute force, we ignore it in favor of the thing that makes it exponentially harder (variable rounds). Similarly, putting port knocking in front of OpenVPN is like putting a padlock on the bank vault. If someone is going to break OpenVPN, port knocking ain't gonna stop them. It is exactly the kind of attacks for which one usually uses iptables. You are right, iptables is just one extra step of security, so the worst thing which can happen is that this step is useless. However, if you are willing to risk this only because of your own lazyness in scripting then why do you setup iptables in the first place? All of my iptables scripts, even the big ones, run in under a second and get executed 2 or 3 times a year. There's some saying about a baby and bath water. It's not laziness I'm advocating, just simplicity. Simple, understandable code is more likely to be correct than clever code. And in this case, incorrect iptables code is more of a threat than the tiny race condition.
Re: [gentoo-user] Network failed and weird error message
Mick wrote: On Sunday 13 Oct 2013 22:49:41 Dale wrote: I don't overclock so I'm not worried about that. I did it once with a old Abit mobo with a AMD 2500+ CPU but it just didn't make much difference. O/C = higher costs. You need higher frequency memory, bigger CPU/case coolers and potentially a bigger PSU. If your budget is constrained then buy memory/cooler/PSU that will run with default settings. The 10% performance improvement that a modern CPU may give you when O/C is not really worth the hassle. I got plenty of all that for sure. My P/S is much to large. The CPU cooler is plain huge for the CPU I got. I don't know what the memory could do but I just run it at stock speeds. When I build a rig, I try to buiild it like a tank. The military type tank. I try to build to last at least 7 or 8 years maybe 9. I'm sort of disappointed if this mobo is going out already. It's way to early for my liking. I think it is only like 3 years old. My old Abit was about 8 years old and it was working fine, just slowly. ;-) Dale :-) :-) -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Gnat Compile Error
On Mon, Oct 14, 2013 at 03:11:30PM +0200, Silvio Siefke wrote: Hello, On Sun, 13 Oct 2013 17:32:29 +0200 Frank Steinmetzger war...@gmx.de wrote: You want to install gnat-gcc for a gcc version you don't have. You have gcc 4.6.3 and 4.7.3 installed (with 4.6.3 active). Unfortunately, my eix doesn't report me any gnat-gcc newer than 4.5. So I'm not sure how to proceed here apart from installing gcc-4.5.4, which is still in portage, but then of course you only have gnat in that old version. But 4.6.3 or 4.7.3 i have not in Portage. [15:07:57][ Akku: 99% ][siefke@gentoomobile:/usr/portage/dev-lang/gnat-gcc]$ ls ChangeLog gnat-gcc-4.2.3.ebuild gnat-gcc-4.4.7.ebuild Manifest gnat-gcc-4.3.5.ebuild gnat-gcc-4.5.4.ebuild files gnat-gcc-4.3.6.ebuild metadata.xml gnat-gcc-3.4.6.ebuild gnat-gcc-4.4.3.ebuild gnat-gcc-4.1.2.ebuild gnat-gcc-4.4.5.ebuild Give Alternatives? As I said, one way is to install gcc 4.5. Another is to build it manually: http://en.wikibooks.org/wiki/Ada_Programming/Installing#The_GNU_Ada_Project leads me to http://sourceforge.net/projects/gnuada/files/ Have a look around there. I’m not sure what files you need or about the versioning, as this page says: Looking for the latest version? Download gnat-gcc-4.2.0-r7.suse_10_2.x86_64.rpm which is even older than what portage offers. -- Gruß | Greetings | Qapla’ Please do not share anything from, with or about me with any Facebook service. The whale is the smallest mammal on Earth, if it just weren’t so big. signature.asc Description: Digital signature
Re: [gentoo-user] Re: Slow network transfers ... lost interrupts because of clocksource?
Am 14.10.2013 08:23, schrieb Stefan G. Weichinger: Am 10.10.2013 16:38, schrieb Stefan G. Weichinger: I don't plan to stay with 3.8.13, this is just an intermediate step to get a working config. For now I don't have any more lost hpet interrupts etc and the LAN speed is fine. Emerging packages as well ... From this config I will then try 3.10.7-r1 again. Went back to 3.10.7-r1 yesterday ... performance fine so far. Today I checked back and found the following in dmesg. Should I disable some option? Thanks for any feedback, Stefan [20788.258330] NMI backtrace for cpu 16 [20788.258334] CPU: 16 PID: 0 Comm: swapper/16 Not tainted 3.10.7-gentoo-r1 #1 [20788.258336] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/10/2012 [20788.258338] task: 88042dcc9fe0 ti: 88042dcd6000 task.ti: 88042dcd6000 [20788.258340] RIP: 0010:[a0006e31] [a0006e31] acpi_idle_enter_simple+0x9e/0xde [processor] [20788.258346] RSP: 0018:88042dcd7e78 EFLAGS: 0093 [20788.258348] RAX: 12e824917a00 RBX: 880c2d1c78a0 RCX: b6e8 [20788.258350] RDX: 0ff9 RSI: 88082fc8 RDI: b6e0 [20788.258352] RBP: 0002 R08: R09: 0192 [20788.258354] R10: 0001 R11: R12: 880c2d1c7800 [20788.258356] R13: 12e605db654b R14: a00087d8 R15: [20788.258358] FS: 7fcbeb7de700() GS:88082fc8() knlGS:f77556c0 [20788.258360] CS: 0010 DS: ES: CR0: 8005003b [20788.258362] CR2: 7fd4098d2000 CR3: 00042d3a4000 CR4: 000407a0 [20788.258364] DR0: 00a0 DR1: DR2: 0003 [20788.258365] DR3: 00b0 DR6: 0ff0 DR7: 0400 [20788.258367] Stack: [20788.258368] 88102ccd4c00 a0008710 0002 8140284b [20788.258371] 01f6 81403b11 [20788.258374] 88102ccd4c00 0002 a0008710 88042dcd7fd8 [20788.258378] Call Trace: [20788.258382] [8140284b] ? cpuidle_enter_state+0x4b/0xe0 [20788.258386] [81403b11] ? ladder_select_state+0x31/0x1e0 [20788.258390] [8140297a] ? cpuidle_idle_call+0x9a/0x140 [20788.258394] [8103b919] ? arch_cpu_idle+0x9/0x30 [20788.258398] [81095439] ? cpu_startup_entry+0x59/0x130 [20788.258399] Code: 01 03 75 02 0f 09 e8 1f 50 08 e1 8a 43 08 3c 01 75 0a 48 89 df e8 c0 78 04 e1 eb 17 3c 02 75 07 e8 0f f9 ff ff eb 0c 8b 53 04 ec 48 8b 15 4c e0 81 e1 ed 31 ff e8 90 50 08 e1 80 7b 08 01 74 10 [20788.258440] NMI backtrace for cpu 20 [20788.258444] CPU: 20 PID: 0 Comm: swapper/20 Not tainted 3.10.7-gentoo-r1 #1 [20788.258445] Hardware name: HP ProLiant DL385p Gen8, BIOS A28 12/10/2012 [20788.258447] task: 88042dccb960 ti: 88042dcde000 task.ti: 88042dcde000 [20788.258449] RIP: 0010:[a0006e31] [a0006e31] acpi_idle_enter_simple+0x9e/0xde [processor] [20788.258456] RSP: 0018:88042dcdfe78 EFLAGS: 0093 [20788.258457] RAX: 12e824919a00 RBX: 880c2d1c50a0 RCX: b6e8 [20788.258459] RDX: 0ff9 RSI: 88082fd0 RDI: b6e0 [20788.258461] RBP: 0002 R08: R09: 0193 [20788.258463] R10: 0001 R11: R12: 880c2d1c5000 [20788.258464] R13: 12e605db857d R14: a00087d8 R15: [20788.258467] FS: 7fcbeb7de700() GS:88082fd0() knlGS:f778d700 [20788.258469] CS: 0010 DS: ES: CR0: 8005003b [20788.258471] CR2: 7fd4098d2000 CR3: 00042d3a4000 CR4: 000407a0 [20788.258473] DR0: 00a0 DR1: DR2: 0003 [20788.258474] DR3: 00b0 DR6: 0ff0 DR7: 0400 [20788.258476] Stack: [20788.258477] 880c2d9e0400 a0008710 0002 8140284b [20788.258480] 01f7 81403b11 [20788.258484] 880c2d9e0400 0002 a0008710 88042dcdffd8 [20788.258487] Call Trace: [20788.258491] [8140284b] ? cpuidle_enter_state+0x4b/0xe0 [20788.258495] [81403b11] ? ladder_select_state+0x31/0x1e0 [20788.258498] [8140297a] ? cpuidle_idle_call+0x9a/0x140 [20788.258502] [8103b919] ? arch_cpu_idle+0x9/0x30 [20788.258506] [81095439] ? cpu_startup_entry+0x59/0x130 [20788.258508] Code: 01 03 75 02 0f 09 e8 1f 50 08 e1 8a 43 08 3c 01 75 0a 48 89 df e8 c0 78 04 e1 eb 17 3c 02 75 07 e8 0f f9 ff ff eb 0c 8b 53 04 ec 48 8b 15 4c e0 81 e1 ed 31 ff e8 90 50 08 e1 80 7b 08 01 74 10 nmo, you should finally go to lkml. Something is very wrong with your setup.
Re: [gentoo-user] Re: scripted iptables-restore
On 2013-10-13 4:07 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: Like passwords, these sequences should better not stay the same for too long... Forced changing of passwords (and I imagine the same can be said for port-knocking sequences, which I've never implemented, but am intrigued by, although I tend to avoid security-through-obscurity schemes) periodically as a way to 'better security' is one of those myths that just never seem to go away. Enforce strong passwords and a policy that no one is to ever write a password down and put it in any publicly accessible place, and educate users how not to fall for phishing attacks, is the single most effective way to keep things secure. Then only change a password if/when an account is compromised. This combined with intelligent rate-limiting (with notifications/warnings to admins if/when a users account exceeds them) is all you need. In fact I go one step further... I assign passwords, and do not even allow users to change them. I have always done this, and we have people in this office that have had the same email password (on the same gentoo server) for 12+ years. I know that I'm probably the exception to this rule, and it is more luck than anything else, but we have never had an email account hacked (knock on wood). I'm certainly not saying we are immune, but the claim that passwords should be forcibly changed for no reason other than the passage of some arbitrary amount of time is just plain dumb.
[gentoo-user] Re: scripted iptables-restore
Michael Orlitzky mich...@orlitzky.com wrote: On 10/14/2013 07:49 AM, Martin Vaeth wrote: Using yet another service with possible holes to protect a sshd? In this case, I would like port knocking at least for this OpenVPN. The sensitive parts of OpenVPN are audited regularly, and it uses SSL -- public key auth to exchange a symmetric key, both of which use tried-and-true algorithms/code. So its completely as well-audited and secure as openssh was when the Debian disaster happened. Also IIRC there are currently some timing attacks against certain SSL modes, and who knows when some clever hacker finds another possibility nobody thought of up to now. Port knocking on the other hand is just security through obscurity As is every password. and is visible over the wire This is why you have to change it regularly. Actually, if you change it whenever you used it, you have a rather strong method, essentially only vulnerable if the man-in-the-middle is able to cut your connection, and even then he has only very limited time to attack the actual service which is protected by it. problem is solved if it's easy to exponentially increase the amount of work an attacker has to do. And exactly for this reason the solution is always only a theory - for very particularly specified problems. For practical machines, it is good to have this *in addition* to other safety measurements: Experience shows that rather often there are some new ideas or bugs which can be used to avoid the exponential amount by something not covered by the original theory. Obscurity does provide some benefit, but it gets dismissed because we tend to ignore the constant factor when talking about these things. This is reasonable for theory, but in practice the constant factor can be more important. Even more if it needs human intervention. Hiding the salt would just be security through obscurity. And yet it is stupid if you do not do it and give away a huge constant factor for no advantage. Similarly, putting port knocking in front of OpenVPN is like putting a padlock on the bank vault. If someone is going to break OpenVPN, port knocking ain't gonna stop them. No. Port knocking is more like putting your bank vault into a wooden box. If some new attack against SSL or the OpenVPN implementation is found, it is like somebody has a key to your vault. If you are a highly important target, this will not save you, but if human resources are needed to break whatever you did for obscurity, it makes in practice the crucial difference. It's not laziness I'm advocating, just simplicity. Simple, understandable code is more likely to be correct than clever code. And in this case, incorrect iptables code is more of a threat than the tiny race condition. You have a strange mentality: One the one hand you are afraid that a rather primitive translation of one syntax into another leads to unexpected effects, and on the other hand you trust much more complex things like SSL and OpenVPN which could much easier allow unexpected things with even the slightest attempt to secure them further if you can.
[gentoo-user] Re: scripted iptables-restore
Tanstaafl tansta...@libertytrek.org wrote: Like passwords, these sequences should better not stay the same for too long... Forced changing of passwords I agreee: To do this to protect *other* users will not work. It's a different thing if you use it for protection of your own data...
Re: [gentoo-user] Re: scripted iptables-restore
On 10/14/2013 02:49 PM, Martin Vaeth wrote: Hiding the salt would just be security through obscurity. And yet it is stupid if you do not do it and give away a huge constant factor for no advantage. (I'll just agree to disagree about the rest.) Keeping the salt secret makes your application more complex. Rather than SELECT hash, salt FROM users WHERE..., you now have to SELECT hash FROM users WHERE... and then pull the salt from somewhere else. (Where? The filesystem? Do you encrypt that? How?) What's stupid is going to all that effort for a 2x improvement when you could twiddle a bit and get a 340282366920938463463374607431768211456x improvement.
Re: [gentoo-user] Re: scripted iptables-restore
On 2013-10-14 2:52 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: Tanstaafl tansta...@libertytrek.org wrote: Like passwords, these sequences should better not stay the same for too long... Forced changing of passwords I agreee: To do this to protect *other* users will not work. It's a different thing if you use it for protection of your own data... True to an extent... but only if the frequency of changing the password doesn't result in you doing something dumb to help you remember the current password of the day - like writing it on a post-it and sticking it underneath the keyboard... ;) One of many reasons why I use a password manager (I prefer the Passwordmaker firefox extension, even with all it warts - it only stores settings, not the passwords themselves)... But there are still only a couple of (critical) passwords I change frequently (what I call frequently - every 3-6 months or more)...
[gentoo-user] Re: Problem with distcc and pump mode: failed to connect to unix-domain: Permission denied
Hello again, Uwe Scholz nurfuern...@web.de schrieb am [Thu, 10.10.2013 10:27]: [...] pump emerge minitube [...] distcc[2815] ERROR: failed to connect to UNIX-DOMAIN /tmp/distcc-pump.boOiEs/socket: Permission denied distcc[2815] (dcc_build_somewhere) Warning: failed to get includes from include server, preprocessing locally I just want to inform you all that I solved the problem with distcc and pump-mode. FEATURE=distcc-pump was missing in my make.conf. With this entry no further errors occur. Ciao, Uwe
[gentoo-user] teamspeak-client-bin-3.0.13
Hey List,
This is my first post, have patience.
Has anyone gotten this problem when updating from teamspeak-client-bin-3.0.12?
Emerging (8 of 8) media-sound/teamspeak-client-bin-3.0.13
* TeamSpeak3-Client-linux_amd64-3.0.13.run SHA256 SHA512 WHIRLPOOL size ;-) ...
[ ok ]
Unpacking source...
Unpacking TeamSpeak3-Client-linux_amd64-3.0.13.run to
/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work
grep:
/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/distdir/TeamSpeak3-Client-linux_amd64-3.0.13.run:
Permission denied
* I'm sorry, but I was unable to support the Makeself file.
* The version I detected was ''.
* Please file a bug about the file TeamSpeak3-Client-linux_amd64-3.0.13.run at
* http://bugs.gentoo.org/ so that support can be added.
* ERROR: media-sound/teamspeak-client-bin-3.0.13::gentoo failed (unpack phase):
* makeself version '' not supported
*
* Call stack:
* ebuild.sh, line 93: Called src_unpack
* environment, line 2278: Called unpacker_src_unpack
* environment, line 2944: Called unpacker
* environment, line 2939: Called _unpacker
'TeamSpeak3-Client-linux_amd64-3.0.13.run'
* environment, line 354: Called unpack_makeself
'/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/distdir/TeamSpeak3-Client-linux_amd64-3.0.13.run'
* environment, line 2839: Called die
* The specific snippet of code:
* die makeself version '${ver}' not supported
*
* If you need support, post the output of `emerge --info
'=media-sound/teamspeak-client-bin-3.0.13::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=media-sound/teamspeak-client-bin-3.0.13::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/temp/environment'.
* Working directory:
'/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work'
* S: '/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work'
My USE flags are as such:
[ebuildfU ~] media-sound/teamspeak-client-bin-3.0.13 [3.0.12] USE=alsa%*
-pulseaudio% 0 kB
There doesn't seem to be any bugs listed about this already.
Thanks for any help.
James
--
This is my signature. Please don't steal it.
Re: [gentoo-user] Re: scripted iptables-restore
On 14/10/2013 21:17, Michael Orlitzky wrote: On 10/14/2013 02:49 PM, Martin Vaeth wrote: Hiding the salt would just be security through obscurity. And yet it is stupid if you do not do it and give away a huge constant factor for no advantage. (I'll just agree to disagree about the rest.) Keeping the salt secret makes your application more complex. Rather than SELECT hash, salt FROM users WHERE..., you now have to SELECT hash FROM users WHERE... and then pull the salt from somewhere else. (Where? The filesystem? Do you encrypt that? How?) What's stupid is going to all that effort for a 2x improvement when you could twiddle a bit and get a 340282366920938463463374607431768211456x improvement. Keep in mind the actual original purpose of a salted hash. If two users happen to use the same password[1], the hashes are the same and this is revealed to anyone who can read /etc/passwd[2] i.e everyone. Salt obscures this 1-to-1 mapping and does it in a way that it is not computationally worth while to try get around it for the general case[3]. It's not quite the same thing as security by obscurity - that is hiding something in a place you think no-one will think of looking but usually turns out to be viable to try and guess. Salt works because brute force now doesn't need just one expensive calculation, it needs many thousands of expensive calculations. If the actual problem is that salt is inadequate, the solution is not to try and hide it, but to use a more complex hashing algorithm with larger salt. It's a race between white and black hats - they build bigger and better rainbow tables, we implement bigger and better hashes. The constraint is how much cpu grunt is available for purchase at a realistic cost. [1] This is not uncommon. The domain size of all possible passwords for a implementation is very very large. Human psychology says that the actual domain size of passwords people will pick is a tiny fraction of the whole. Hence salt. [2] Nowadays we use shadow, but the development of salt pre-dates shadow -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] Re: scripted iptables-restore
On 14/10/2013 20:23, Tanstaafl wrote: On 2013-10-13 4:07 PM, Martin Vaeth va...@mathematik.uni-wuerzburg.de wrote: Like passwords, these sequences should better not stay the same for too long... Forced changing of passwords (and I imagine the same can be said for port-knocking sequences, which I've never implemented, but am intrigued by, although I tend to avoid security-through-obscurity schemes) periodically as a way to 'better security' is one of those myths that just never seem to go away. Enforce strong passwords and a policy that no one is to ever write a password down and put it in any publicly accessible place, and educate users how not to fall for phishing attacks, is the single most effective way to keep things secure. Then only change a password if/when an account is compromised. Here here. I fully agree, and I have a use case to back you up. Yes, it's anecdotal and just my use case, but at least it's factual :-) Access to my backend network is two-factor - ssh keys and decent passwords. I generate the passwords in code, they have high randomity but rememberable and I refuse to implement password expiry. People with sensitive and powerful accounts have enough head smarts to know when to tell me quietly they need a reset done, and everyone is happy with this. they don't mind that I see their passwords once in plaintext, as I can make the password anything I want anytime I want. The user's security against me comes via the HR department backed up by employment law. We have pentesters that exhaustively test stuff every few months. I insist they have full access to my data, supervised by the very trusted Risk guy, as I want them to find any weakness as opposed to the bad guys finding them. In 5 years they have cracked one password once out of many hundreds. One. It's an isolated case and I know how it happened - I trusted someone and bent one rule once. Contrast the scheme used by Windows. It uses every one of these best practice tricks inccluding expiring every 30 days, password length, complexity, special chars etc. With every audit it gets blown wide open, usually within a few hours. reason: human being are almost uniformly bad at selecting and maintaining passwords. I break all the best practice rules and have never have a systemic compromise in 5 years despite awesome tools weilded by real pros with clue throwing the book at it. Hmmm. The other system that does obey best practice gets ripped to pieces with trivial ease by the same guys. Hmmm. I can pull this off because a) few people dare go up against me and my facts :-) and b) it's a controlled environment. Obviously this couldn't work on a public service like say gmail. This combined with intelligent rate-limiting (with notifications/warnings to admins if/when a users account exceeds them) is all you need. In fact I go one step further... I assign passwords, and do not even allow users to change them. I have always done this, and we have people in this office that have had the same email password (on the same gentoo server) for 12+ years. I know that I'm probably the exception to this rule, and it is more luck than anything else, but we have never had an email account hacked (knock on wood). I'm certainly not saying we are immune, but the claim that passwords should be forcibly changed for no reason other than the passage of some arbitrary amount of time is just plain dumb. -- Alan McKinnon alan.mckin...@gmail.com
[gentoo-user] Re: teamspeak-client-bin-3.0.13
On 10/14/2013 01:27 PM, james wrote: Hey List, This is my first post, have patience. Has anyone gotten this problem when updating from teamspeak-client-bin-3.0.12? Emerging (8 of 8) media-sound/teamspeak-client-bin-3.0.13 * TeamSpeak3-Client-linux_amd64-3.0.13.run SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] Unpacking source... Unpacking TeamSpeak3-Client-linux_amd64-3.0.13.run to /var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work grep: /var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/distdir/TeamSpeak3-Client-linux_amd64-3.0.13.run: Permission denied ^ That error message is very odd, and very early in the emerge process, too. Maybe using the -d (debug) flag with emerge would give some useful clues.
Re: [gentoo-user] Re: scripted iptables-restore
On 10/14/2013 04:31 PM, Alan McKinnon wrote: Keep in mind the actual original purpose of a salted hash. If two users happen to use the same password[1], the hashes are the same and this is revealed to anyone who can read /etc/passwd[2] i.e everyone. Ah, the single-entry rainbow table =)
[gentoo-user] using lvm without a partition of type linux LVM
In linux.gentoo.user, allan wrote: On Sat, Oct 12 2013, thana...@asyr.hopto.org wrote: on 10/12/2013 05:40 PM gottl...@nyu.edu wrote the following: copy the lvm partitions to directories on an external disk (ext3) What command did you use for copying? cp -ax rsync not is on the minimal install. rsync is on my 2013 amd-x64 minimal install CD. Do you have an amd-x64 install and do you have the latest version of the minimal install CD? -- Regards, Gregory.
Re: [gentoo-user] Re: teamspeak-client-bin-3.0.13
On 10/14/2013 04:06 PM, walt wrote: On 10/14/2013 01:27 PM, james wrote: Hey List, This is my first post, have patience. Has anyone gotten this problem when updating from teamspeak-client-bin-3.0.12? Emerging (8 of 8) media-sound/teamspeak-client-bin-3.0.13 * TeamSpeak3-Client-linux_amd64-3.0.13.run SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] Unpacking source... Unpacking TeamSpeak3-Client-linux_amd64-3.0.13.run to /var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work grep: /var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/distdir/TeamSpeak3-Client-linux_amd64-3.0.13.run: Permission denied ^ That error message is very odd, and very early in the emerge process, too. Maybe using the -d (debug) flag with emerge would give some useful clues. I've checked it, Though I'm a Gentoo user, and have been for years, I'm not a power user. Nothing *seems* to stand out. Would you recommend i submit a bug or share the debug typescript whith the List? Thanks -- This is my signature. Please don't steal it.
[gentoo-user] New mobo change
Howdy, I ordered the new mobo as much as I needed to wait. The mobo is the same brand but a different chipset and a couple other things are different. I have already built a kernel for those changes. I plan to put everything on the old mobo on the new mobo. That includes the CPU. I'm pretty sure this will not be needed but want to ask to be sure. Do I need to do a emerge -e world or should it just work like it is? Since the CPU is going to be the exact same CPU, I'm thinking it is not needed. I do have march=native set in make.conf. Thoughts? Thanks. Dale :-) :-) P. S. I think this is the most I have ever spent on a mobo. $120.00 with shipping. -- I am only responsible for what I said ... Not for what you understood or how you interpreted my words!
Re: [gentoo-user] Re: teamspeak-client-bin-3.0.13
james ja...@flatlan.net wrote: On 10/14/2013 04:06 PM, walt wrote: On 10/14/2013 01:27 PM, james wrote: Hey List, This is my first post, have patience. Has anyone gotten this problem when updating from teamspeak-client-bin-3.0.12? Emerging (8 of 8) media-sound/teamspeak-client-bin-3.0.13 * TeamSpeak3-Client-linux_amd64-3.0.13.run SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] Unpacking source... Unpacking TeamSpeak3-Client-linux_amd64-3.0.13.run to /var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work grep: /var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/distdir/TeamSpeak3-Client-linux_amd64-3.0.13.run: Permission denied ^ That error message is very odd, and very early in the emerge process, too. Maybe using the -d (debug) flag with emerge would give some useful clues. I've checked it, Though I'm a Gentoo user, and have been for years, I'm not a power user. Nothing *seems* to stand out. Would you recommend i submit a bug or share the debug typescript whith the List? Thanks -- This is my signature. Please don't steal it. Can you send the output of emerge --info and your /etc/fstab file? -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: [gentoo-user] New mobo change
On Oct 15, 2013 10:51 AM, Dale rdalek1...@gmail.com wrote: Howdy, I ordered the new mobo as much as I needed to wait. The mobo is the same brand but a different chipset and a couple other things are different. I have already built a kernel for those changes. I plan to put everything on the old mobo on the new mobo. That includes the CPU. I'm pretty sure this will not be needed but want to ask to be sure. Do I need to do a emerge -e world or should it just work like it is? Since the CPU is going to be the exact same CPU, I'm thinking it is not needed. I do have march=native set in make.conf. Thoughts? Thanks. Personally, I think all you need to do is to ensure that the kernel has all the drivers it needs to speak to the new mobo. Other members of the @world set relies on the drivers in the kernel. But I don't use any GUI or audio; if you're using a GUI and/or audio, you might also have to re-emerge the relevant bits. BSTS: just re-emerge @world :-) Rgds, --
Re: [gentoo-user] Re: teamspeak-client-bin-3.0.13
On 10/14/2013 10:21 PM, jo...@antarean.org wrote: james ja...@flatlan.net wrote: On 10/14/2013 04:06 PM, walt wrote: On 10/14/2013 01:27 PM, james wrote: Hey List, This is my first post, have patience. Has anyone gotten this problem when updating from teamspeak-client-bin-3.0.12? Emerging (8 of 8) media-sound/teamspeak-client-bin-3.0.13 * TeamSpeak3-Client-linux_amd64-3.0.13.run SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] Unpacking source... Unpacking TeamSpeak3-Client-linux_amd64-3.0.13.run to /var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work grep: /var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/distdir/TeamSpeak3-Client-linux_amd64-3.0.13.run: Permission denied ^ That error message is very odd, and very early in the emerge process, too. Maybe using the -d (debug) flag with emerge would give some useful clues. I've checked it, Though I'm a Gentoo user, and have been for years, I'm not a power user. Nothing *seems* to stand out. Would you recommend i submit a bug or share the debug typescript whith the List? Thanks Can you send the output of emerge --info and your /etc/fstab file? -- Joost -- Sent from my Android device with K-9 Mail. Please excuse my brevity. fstab: # NOTE: If your BOOT partition is ReiserFS, add the notail option to opts. UUID= /ext4relatime,discard 0 1 UUID= /boot ext2noauto,noatime 1 2 /dev/mapper/crypt-secure/secure ext4relatime,noauto 0 0 /dev/mapper/crypt-swap noneswapsw 0 0 tmpfs /tmptmpfs nodev,nosuid0 0 tmpfs /var/tmp/portage tmpfs nodev,nosuid,rw,size=8G 0 0 /dev/sr0/mnt/dvd auto nosuid,nodev,user,noauto 0 0 LABEL=30/mnt/usb ext4 users,rw0 0 LABEL=HDD /mnt/HDD ext4 nosuid,nodev,nofail,noauto 0 0 Portage 2.2.7 (default/linux/amd64/13.0, gcc-4.8.1, glibc-2.15-r3, 3.11.1-gentoo x86_64) = System uname: Linux-3.11.1-gentoo-x86_64-Intel-R-_Core-TM-_i5-2520M_CPU_@_2.50GHz-with-gentoo-2.2 KiB Mem:16291504 total, 9308624 free KiB Swap:4194300 total, 4194300 free Timestamp of tree: Mon, 14 Oct 2013 18:15:01 + ld GNU ld (GNU Binutils) 2.23.1 app-shells/bash: 4.2_p45 dev-java/java-config: 2.1.12-r1 dev-lang/python: 2.7.5-r2, 3.2.5-r2 dev-util/cmake: 2.8.10.2-r2 dev-util/pkgconfig: 0.28 sys-apps/baselayout: 2.2 sys-apps/openrc: 0.11.8 sys-apps/sandbox: 2.6-r1 sys-devel/autoconf: 2.13, 2.69 sys-devel/automake: 1.11.6, 1.12.6, 1.13.4 sys-devel/binutils: 2.23.1 sys-devel/gcc:4.8.1-r1 sys-devel/gcc-config: 1.8 sys-devel/libtool:2.4.2 sys-devel/make: 3.82-r4 sys-kernel/linux-headers: 3.11 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ananke Installed sets: @kernel ACCEPT_KEYWORDS=amd64 ACCEPT_LICENSE=* -@EULA AdobeFlash-10.3 -dlj-1.1 -googleearth -Oracle-BCLA-JavaSE CBUILD=x86_64-pc-linux-gnu CFLAGS=-march=native -O2 -pipe CHOST=x86_64-pc-linux-gnu CONFIG_PROTECT=/etc /usr/share/gnupg/qualified.txt CONFIG_PROTECT_MASK=/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo CXXFLAGS=-march=native -O2 -pipe DISTDIR=/usr/portage/distfiles EMERGE_DEFAULT_OPTS=--color=y FCFLAGS=-O2 -pipe FEATURES=assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr FFLAGS=-O2 -pipe GENTOO_MIRRORS=http://distfiles.gentoo.org/; LANG=en_US.UTF-8 LDFLAGS=-Wl,-O1 -Wl,--as-needed MAKEOPTS=-j6 PKGDIR=/usr/portage/packages PORTAGE_CONFIGROOT=/ PORTAGE_RSYNC_OPTS=--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages PORTAGE_TMPDIR=/var/tmp PORTDIR=/usr/portage PORTDIR_OVERLAY=/usr/local/portage SYNC=rsync://rsync25.us.gentoo.org/gentoo-portage USE=X a52 acl acpi aio alsa amd64 apng avx bash-completion berkdb bluray bzip2 c++0x cdda cddb cdparanoia cdr cli consolekit cracklib crypt css cxx dri dts dvd dvdnav dvdr dvdread egl faac faad ffmpeg flac fortran gdbm gif git gnutls gpg iconv icu id3 ipv6
Re: [gentoo-user] teamspeak-client-bin-3.0.13
Hello James,
yes, I've also had this problem. Check the permissions of the
TeamSpeak3-Client-linux_amd64-3.0.13.run file you downloaded and moved
to /usr/portage/distfiles. This file is maybe still owned by your user.
After I changed the owner and group of the file to portage and set the
permissions like the other files in /usr/portage/distfiles the package
installs without problems. Owner, group and permissions look like this
on my system:
-rw-rw-r-- 1 portage portage 33205868 8. Okt 08:33
TeamSpeak3-Client-linux_amd64-3.0.13.run
Best regards,
Jens
Am 14.10.2013 22:27, schrieb james:
Hey List,
This is my first post, have patience.
Has anyone gotten this problem when updating from teamspeak-client-bin-3.0.12?
Emerging (8 of 8) media-sound/teamspeak-client-bin-3.0.13
* TeamSpeak3-Client-linux_amd64-3.0.13.run SHA256 SHA512 WHIRLPOOL size ;-)
...
[ ok ]
Unpacking source...
Unpacking TeamSpeak3-Client-linux_amd64-3.0.13.run to
/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work
grep:
/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/distdir/TeamSpeak3-Client-linux_amd64-3.0.13.run:
Permission denied
* I'm sorry, but I was unable to support the Makeself file.
* The version I detected was ''.
* Please file a bug about the file TeamSpeak3-Client-linux_amd64-3.0.13.run
at
* http://bugs.gentoo.org/ so that support can be added.
* ERROR: media-sound/teamspeak-client-bin-3.0.13::gentoo failed (unpack
phase):
* makeself version '' not supported
*
* Call stack:
* ebuild.sh, line 93: Called src_unpack
* environment, line 2278: Called unpacker_src_unpack
* environment, line 2944: Called unpacker
* environment, line 2939: Called _unpacker
'TeamSpeak3-Client-linux_amd64-3.0.13.run'
* environment, line 354: Called unpack_makeself
'/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/distdir/TeamSpeak3-Client-linux_amd64-3.0.13.run'
* environment, line 2839: Called die
* The specific snippet of code:
* die makeself version '${ver}' not supported
*
* If you need support, post the output of `emerge --info
'=media-sound/teamspeak-client-bin-3.0.13::gentoo'`,
* the complete build log and the output of `emerge -pqv
'=media-sound/teamspeak-client-bin-3.0.13::gentoo'`.
* The complete build log is located at
'/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/temp/build.log'.
* The ebuild environment file is located at
'/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/temp/environment'.
* Working directory:
'/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work'
* S: '/var/tmp/portage/media-sound/teamspeak-client-bin-3.0.13/work'
My USE flags are as such:
[ebuildfU ~] media-sound/teamspeak-client-bin-3.0.13 [3.0.12] USE=alsa%*
-pulseaudio% 0 kB
There doesn't seem to be any bugs listed about this already.
Thanks for any help.
James
Re: OT - RAM disks - WAS Re: [gentoo-user] Network failed and weird error message
On Oct 14, 2013 6:04 PM, Tanstaafl tansta...@libertytrek.org wrote: On 2013-10-13 5:49 PM, Dale rdalek1...@gmail.com wrote: Talk about putting some stuff on tmpfs. O_O I have always wanted to copy the tree to tmpfs and run time emerge -uvaDN world. Just to see how fast it will go. lol I remember once I worked for an Apple reseller that had this accounting program that required them to do some kind of 'reconciliation' every month that required a massive amount of processing - it took like 36 hours or something ridiculous (literally almost took all weekend), and he had implemented a rule that someone had to be there the entire time to baby sit the process - apparently it wasn't uncommon for there to be an error that would require them to restart it - and this was on a pretty powerful system at the time. Well, one weekend, when we were building a system for a customer with tons of RAM (for the time) I talked them into a little experiment. The boss didn't believe me when I told him I could get the reconciliation processing time down to less than a day (I told him probably just a few hours, but wasn't sure)... so we made a bet. I took a Quadra 900 (or maybe it was a 950), and added a bunch of RAM - I think we got it up to 128MB or something ridiculous (this was in about 1992). The accounting DB was about 40MB at the time, but hey, we had the RAM, so I just loaded it up. I created a RAM disk, copied the entire Accounting DB into it, and started running the reconciliation. The process finished after about 45 minutes (I was even surprised at that), and while there were no errors and it said it had completed successfully, the boss was sure that something had gone wrong. So, he re-ran it the old way on the old server, and almost 2 days later, when the numbers matched, he just shook his head and paid me off, muttering about the lost weekends over the last 5 years he'd been there. He kept that machine around for running the reconciliation for at least a few months, but then I left, so no idea how long he kept it for... Nce.. 48x performance improvement? I know of some DBA who would gladly pay an arm + a leg + their grandmothers for that kind of improvement :-) Kind of tangential, but that's what Oracle is aiming with their TimesTen product: give the server oodles of RAM, and load the database in memory. Another similar performance-improving method would be using Fusion-IO to load the database into direct-memory-mapped SSDs. They claimed that the most high-end Fusion-IO devices can reach up to 9 million IOPS... Rgds, --
