Re: [gentoo-user] Ghost cyber threat
Does anybody know more about this security flaw in the open-source Linux GNU C Library http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1 I updated a system of mine that was using an old version of glibc and rebooted. I can't do a full emerge world there or use various other portage tools due to the peculiarities of my current situation. Could I still be vulnerable? - Grant
Re: [gentoo-user] updating netbook : Python needs libjpeg.so.8 : solved
On Thu, 29 Jan 2015 05:52:27 -0500 Philip Webb wrote: The 3rd stumble was Python, which refused to compile, as it couldn't find /usr/lib/libjpeg.so.8 . It seems that Libjpeg-turbo works only on 64-bit systems that 32-bit systems like my netbook have to use simple Jpeg. No. libjpeg-turbo works fine here on ~x86. Best regards, Andrew Savchenko pgpKWytHpmp4L.pgp Description: PGP signature
Re: [gentoo-user] Re: Ghost cyber threat
On Wed, 28 Jan 2015 15:01:26 + (UTC) James wrote: Philip Webb purslow at ca.inter.net writes: 150127 Joseph wrote: Does anybody know more about this security flaw in the open-source Linux GNU C Library : http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1 Acc to this, it was patched 2013 today threatens only long-term systems : http://threatpost.com/ghost-glibc-remote-code-execution-vulnerability-affects-all-linux-systems/110679 I'm running 2.19-r1 , installed 140802 ; vulnerable are 2.18 . Linux systems are at risk only when admins don't keep versions upto-date. Maybe it's time to looking into some of the work the gentoo hardened devs have going on: http://wiki.gentoo.org/wiki/Project:Hardened_musl 1. Main security is outdated software. E.g. ghost bug affects only very old setups. 2. There is no proof that musl is more secure than glibc. Smaller codebase tends to have less bugs, of course; but audience of musl is multiple degrees smaller than that of glibc, thus many bugs are just likely to be undiscovered. With more users and features musl will also have critical bugs sooner or later. These reminds me of recent openssl issue, after which many switched to polarssl and that one had a critical security bug just recently. Best regards, Andrew Savchenko pgpvLwbU7JNjE.pgp Description: PGP signature
[gentoo-user] Regular user unable to use sound/alsa after upgrade
With the latest Flash vulnerability, I ran an update, which pulled in Flash and a few other items. I also upgraded from linux-3.16.5-gentoo to linux-3.17.7-gentoo, with the usual make oldconfig routine, and set CPU_FLAGS_X86=mmx mmxext sse sse2 sse3 ssse3 as indicated by cpuinfo2cpuflags-x86. After rebooting, regular user (both waltdnes and user2) could no longer play audio, but root could. I have a lilo menu that has 2 entries Production, and Experimental. A new kernel is always Experimental until I run it for a while without problems. I reverted to Production (3.16.5) but that didn't help. Before everybody jumps in with the standard response, yes I am a member of group audio. [d531][root][~] grep audio /etc/group* /etc/group:audio:x:18:waltdnes,user2 /etc/group-:audio:x:18:waltdnes,user2 Audio has worked for years on this system before the problem. I took a better look at the error messages, and had a WTF moment. mpg123 (and mplayer and FLASH) appears to be looking for some libraries in /var/tmp/portage/ as regular user, but root works fine. Why would a regular user app look there, when root appears to work fine? Here are the error messages for mpg123 ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/conf.c:4259:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/conf.c:4259:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/conf.c:4738:(snd_config_expand) Evaluate error: No such file or directory ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/pcm/pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM default [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/output/alsa.c:170] error: cannot open device default [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/audio.c:630] error: failed to open audio device [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/audio.c:180] error: Unable to find a working output module in this list: alsa [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/audio.c:532] error: Failed to open audio output module [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/mpg123.c:913] error: Failed to initialize output, goodbye. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Usign ansible
sorry ... still a bit OT but maybe interesting for others as well: Yesterday I started to modify the following ansible role to fit my needs and work with gentoo target hosts: https://github.com/debops/ansible-dhcpd I modified tasks/main.yml (use portage ... install iproute2 as well) and edited defaults/main.yml to reflect the environment of site A at first. my first testing playbook: --- - hosts: site-A-dhcpd user: root roles: - ansible-dhcpd Now I wonder how to use the same role for configuring site B. defaults/main.yml currently contains the config (vars ... yes) for site A ... A copy of the role is way too redundant ... What is the/a correct and elegant way to do that? Have a defaults/site-B.conf.yml or something and include that in a 2nd playbook? Use some file in the vars/ directory ... ? I am quite sure that this is just a beginner's problem ... but in these days my brain is a bit exhausted by my current workload etc Thanks for any hints, Stefan!
Re: [gentoo-user] Usign ansible
On 2015-01-29 09:43, Stefan G. Weichinger wrote: sorry ... still a bit OT but maybe interesting for others as well: Yesterday I started to modify the following ansible role to fit my needs and work with gentoo target hosts: https://github.com/debops/ansible-dhcpd I modified tasks/main.yml (use portage ... install iproute2 as well) and edited defaults/main.yml to reflect the environment of site A at first. my first testing playbook: --- - hosts: site-A-dhcpd user: root roles: - ansible-dhcpd Now I wonder how to use the same role for configuring site B. defaults/main.yml currently contains the config (vars ... yes) for site A ... A copy of the role is way too redundant ... What is the/a correct and elegant way to do that? Have a defaults/site-B.conf.yml or something and include that in a 2nd playbook? Use some file in the vars/ directory ... ? I am quite sure that this is just a beginner's problem ... but in these days my brain is a bit exhausted by my current workload etc Thanks for any hints, Stefan! Have your IPs listed in hosts-production. For each site create a file, like: site_A.yml - hosts: site_A roles: - ... site_B.yml - hosts: site_B roles: - ... Then create site.yml where you include site_A.yml and site_B.yml. Mostly, you will not only use roles inclusion, but have something special done on the server, so either you create a role corresponding to this file (like role site_A, site_B) where you name the tasks or you put it directly in the site_A.yml, site_B.yml file. This is the stuff unique to the server, like creating a specific user, specific directory, with specific files... Then if you want to reconfigure all, just ansible-playbook -i hosts-production site.yml Only site_A: ansible-playbook -i hosts-production site_A.yml Only configure postfix on site_B: ansible-playbook -i hosts-production site_B.yml --tags postfix -v Read: http://docs.ansible.com/playbooks_roles.html http://docs.ansible.com/playbooks_best_practices.html
Re: [gentoo-user] Usign ansible
I haven't migrated to group_vars yet, so try and let us know ;) On Thu, Jan 29, 2015 at 11:14 AM, Stefan G. Weichinger li...@xunil.at wrote: On 29.01.2015 10:47, Tomas Mozes wrote: Have your IPs listed in hosts-production. For each site create a file, like: site_A.yml - hosts: site_A roles: - ... site_B.yml - hosts: site_B roles: - ... Then create site.yml where you include site_A.yml and site_B.yml. Mostly, you will not only use roles inclusion, but have something special done on the server, so either you create a role corresponding to this file (like role site_A, site_B) where you name the tasks or you put it directly in the site_A.yml, site_B.yml file. This is the stuff unique to the server, like creating a specific user, specific directory, with specific files... Then if you want to reconfigure all, just ansible-playbook -i hosts-production site.yml Only site_A: ansible-playbook -i hosts-production site_A.yml Only configure postfix on site_B: ansible-playbook -i hosts-production site_B.yml --tags postfix -v Read: http://docs.ansible.com/playbooks_roles.html http://docs.ansible.com/playbooks_best_practices.html Thanks, Tomas ... yes and no ... ;-) I wonder if I could also: cp defaults/main.yml to group_vars/site_[AB].yml ... adjust the configs to the sites and then use something like: # playbook 1 - hosts: site_A roles: - dhcpd # playbook 2 - hosts: site_B roles: - dhcpd would the group_vars override the vars defined in defaults/main.yml ? I *think* so ... I will try that ... Stefan
Re: [gentoo-user] Usign ansible
On 29.01.2015 10:47, Tomas Mozes wrote: Have your IPs listed in hosts-production. For each site create a file, like: site_A.yml - hosts: site_A roles: - ... site_B.yml - hosts: site_B roles: - ... Then create site.yml where you include site_A.yml and site_B.yml. Mostly, you will not only use roles inclusion, but have something special done on the server, so either you create a role corresponding to this file (like role site_A, site_B) where you name the tasks or you put it directly in the site_A.yml, site_B.yml file. This is the stuff unique to the server, like creating a specific user, specific directory, with specific files... Then if you want to reconfigure all, just ansible-playbook -i hosts-production site.yml Only site_A: ansible-playbook -i hosts-production site_A.yml Only configure postfix on site_B: ansible-playbook -i hosts-production site_B.yml --tags postfix -v Read: http://docs.ansible.com/playbooks_roles.html http://docs.ansible.com/playbooks_best_practices.html Thanks, Tomas ... yes and no ... ;-) I wonder if I could also: cp defaults/main.yml to group_vars/site_[AB].yml ... adjust the configs to the sites and then use something like: # playbook 1 - hosts: site_A roles: - dhcpd # playbook 2 - hosts: site_B roles: - dhcpd would the group_vars override the vars defined in defaults/main.yml ? I *think* so ... I will try that ... Stefan
Re: [gentoo-user] iscsitarget or targetcli?
On 29/01/15 10:25, J. Roeleveld wrote: Hi all, I want to set up an iSCSI server (target in iSCSI terminology) running on Gentoo. Does anyone know which of the following 2 are better: - sys-block/iscsitarget - sys-block/targetcli Both don't seem to have had an update for over 2 years, but targetcli seems to be just the config-tool for whatever is in current kernels where, I think, iscsitarget is a userspace daemon? Many thanks, Joost I'd actually suggest using SCST http://monklinux.blogspot.ie/2012/02/scst-configuration-how-to-using-gentoo.html works very well and has a few extra niceties (dynamic resize notification being one) that seem to be missing on other iscsi targets. nice and easy syntax too
[gentoo-user] iscsitarget or targetcli?
Hi all, I want to set up an iSCSI server (target in iSCSI terminology) running on Gentoo. Does anyone know which of the following 2 are better: - sys-block/iscsitarget - sys-block/targetcli Both don't seem to have had an update for over 2 years, but targetcli seems to be just the config-tool for whatever is in current kernels where, I think, iscsitarget is a userspace daemon? Many thanks, Joost
Re: [gentoo-user] iscsitarget or targetcli?
On 29/01/15 11:25, J. Roeleveld wrote: Hi all, I want to set up an iSCSI server (target in iSCSI terminology) running on Gentoo. Does anyone know which of the following 2 are better: - sys-block/iscsitarget - sys-block/targetcli Both don't seem to have had an update for over 2 years, but targetcli seems to be just the config-tool for whatever is in current kernels where, I think, iscsitarget is a userspace daemon? Many thanks, Joost Hi, sys-block/iscsitarget is composed of a kernel module and a userspace daemon, both compiled and installed by the ebuild. I would second the recommendation for SCST, which is actively developed and in my experience is quite more stable and tends to recover better from unexpected events than sys-block/iscsitarget (I have used both for quite some time). The only downside of SCST is that it requires a bit more work to install, mainly because there is no ebuild for it; moreover, while it can be built against and run on a stock kernel, it comes with a couple of kernel patches which should be applied for optimal performance or are needed fot specific features (e.g. the vdisk backend). andrea
[gentoo-user] updating netbook : Python needs libjpeg.so.8 : solved
The 3rd stumble was Python, which refused to compile, as it couldn't find /usr/lib/libjpeg.so.8 . It seems that Libjpeg-turbo works only on 64-bit systems that 32-bit systems like my netbook have to use simple Jpeg. -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] iscsitarget or targetcli?
What is the difference between the kernel-stuff (targetcli is only the config- tool) and scst? http://scst.sourceforge.net/comparison.html It was written by the SCST team, so it should be taken with a grain of salt; it is nonetheless a useful overview of the alternatives out there. andrea
Re: [gentoo-user] iscsitarget or targetcli?
On Thursday, January 29, 2015 11:28:56 AM thegeezer wrote: On 29/01/15 10:25, J. Roeleveld wrote: Hi all, I want to set up an iSCSI server (target in iSCSI terminology) running on Gentoo. Does anyone know which of the following 2 are better: - sys-block/iscsitarget - sys-block/targetcli Both don't seem to have had an update for over 2 years, but targetcli seems to be just the config-tool for whatever is in current kernels where, I think, iscsitarget is a userspace daemon? Many thanks, Joost I'd actually suggest using SCST http://monklinux.blogspot.ie/2012/02/scst-configuration-how-to-using-gentoo. html works very well and has a few extra niceties (dynamic resize notification being one) that seem to be missing on other iscsi targets. nice and easy syntax too I managed to get dynamic resizing working when I did my first tests with targetcli and the kernel-inbuild stuff: Device Drivers --- M Generic Target Core Mod (TCM) and ConfigFS Infrastructure --- M TCM/IBLOCK Subsystem Plugin for Linux/BLOCK M TCM/FILEIO Subsystem Plugin for Linux/VFS M TCM/pSCSI Subsystem Plugin for Linux/SCSI M Linux-iSCSI.org iSCSI Target Mode Stack I only had to tell the iscsi-client to recheck the new size: server : # resize filesystem (Server was using targetcli with the kernel-inbuild stuff) client : # iscsiadm -m node -T iqnvm5... -R client : # resize2fs /dev/sdb What is the difference between the kernel-stuff (targetcli is only the config- tool) and scst? -- Joost
[gentoo-user] Re: [SOLVED] Regular user unable to use sound/alsa after upgrade
On Thu, Jan 29, 2015 at 12:52:58PM -0500, cov...@ccs.covici.com wrote I would check the permissions of /dev/dsp and /dev/snd maybe they should be world rw or something. The /var/tmp is just what the source directory is, don't worry about that. No /dev/dsp on my system. As for /dev/snd [d531][waltdnes][~] ll /dev/snd total 0 drwxr-xr-x 2 root root 160 Jan 28 21:50 . drwxr-xr-x 16 root root3400 Jan 29 02:50 .. crw-rw 1 root root 116, 2 Jan 28 21:50 controlC0 crw-rw 1 root root 116, 4 Jan 28 21:50 pcmC0D0c crw-rw 1 root root 116, 3 Jan 29 12:24 pcmC0D0p crw-rw 1 root root 116, 5 Jan 28 21:50 pcmC0D2c crw-rw 1 root root 116, 1 Jan 28 21:50 seq crw-rw 1 root root 116, 33 Jan 28 21:50 timer I went in as root and changed the entire snd subdirectory to root:users [d531][waltdnes][~] ll /dev/snd total 0 drwxr-xr-x 2 root users 160 Jan 28 21:50 . drwxr-xr-x 16 root root 3400 Jan 29 02:50 .. crw-rw 1 root users 116, 2 Jan 28 21:50 controlC0 crw-rw 1 root users 116, 4 Jan 28 21:50 pcmC0D0c crw-rw 1 root users 116, 3 Jan 29 13:05 pcmC0D0p crw-rw 1 root users 116, 5 Jan 28 21:50 pcmC0D2c crw-rw 1 root users 116, 1 Jan 28 21:50 seq crw-rw 1 root users 116, 33 Jan 28 21:50 timer ...and now sound works fine as regular user. Thank you very much for the solution. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Question about flakey RAM
On 01/27/2015 03:28 PM, walt wrote: My question is why didn't memtest86+ find any errors? Could it be that the first RAM I bought was actually okay but this machine didn't like it for some reason? Both were DDR3/1333MHz, just from different manufacturers. If the timing/voltage is set wrong in the BIOS this can happen. I had bad memory sticks where the BIOS assumed certain timings and voltage, but when I set them to the manufacturers recommendations (manually changing voltage and timings, and no, I was not overclocking...) they were fine. I ran the memory I had in its bad state and memtest checked out okay after leaving it for three days straight testing. Weirdest thing I'd ever seen. Dan
[gentoo-user] Chrome window
Hello, since V 40 from Google Chrome the Browser will not imaging the complete window. Only when open tab or open link the complete window will work Has someone same expierence and found fix? http://pasteboard.co/IZI3x7U.png Thank you for help Nice Day Silvio
Re: [gentoo-user] Regular user unable to use sound/alsa after upgrade
Walter Dnes waltd...@waltdnes.org wrote: With the latest Flash vulnerability, I ran an update, which pulled in Flash and a few other items. I also upgraded from linux-3.16.5-gentoo to linux-3.17.7-gentoo, with the usual make oldconfig routine, and set CPU_FLAGS_X86=mmx mmxext sse sse2 sse3 ssse3 as indicated by cpuinfo2cpuflags-x86. After rebooting, regular user (both waltdnes and user2) could no longer play audio, but root could. I have a lilo menu that has 2 entries Production, and Experimental. A new kernel is always Experimental until I run it for a while without problems. I reverted to Production (3.16.5) but that didn't help. Before everybody jumps in with the standard response, yes I am a member of group audio. [d531][root][~] grep audio /etc/group* /etc/group:audio:x:18:waltdnes,user2 /etc/group-:audio:x:18:waltdnes,user2 Audio has worked for years on this system before the problem. I took a better look at the error messages, and had a WTF moment. mpg123 (and mplayer and FLASH) appears to be looking for some libraries in /var/tmp/portage/ as regular user, but root works fine. Why would a regular user app look there, when root appears to work fine? Here are the error messages for mpg123 ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/confmisc.c:768:(parse_card) cannot find card '0' ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/conf.c:4259:(_snd_config_evaluate) function snd_func_card_driver returned error: No such file or directory ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/confmisc.c:392:(snd_func_concat) error evaluating strings ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/conf.c:4259:(_snd_config_evaluate) function snd_func_concat returned error: No such file or directory ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/confmisc.c:1251:(snd_func_refer) error evaluating name ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/conf.c:4259:(_snd_config_evaluate) function snd_func_refer returned error: No such file or directory ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/conf.c:4738:(snd_config_expand) Evaluate error: No such file or directory ALSA lib /var/tmp/portage/media-libs/alsa-lib-1.0.28/work/alsa-lib-1.0.28/src/pcm/pcm.c:2239:(snd_pcm_open_noupdate) Unknown PCM default [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/output/alsa.c:170] error: cannot open device default [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/audio.c:630] error: failed to open audio device [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/audio.c:180] error: Unable to find a working output module in this list: alsa [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/audio.c:532] error: Failed to open audio output module [/var/tmp/portage/media-sound/mpg123-1.18.1/work/mpg123-1.18.1/src/mpg123.c:913] error: Failed to initialize output, goodbye. I would check the permissions of /dev/dsp and /dev/snd maybe they should be world rw or something. The /var/tmp is just what the source directory is, don't worry about that. -- Your life is like a penny. You're going to lose it. The question is: How do you spend it? John Covici cov...@ccs.covici.com
Re: [gentoo-user] Ghost cyber threat
On Thu, 29 Jan 2015 08:52:57 -0800 Grant wrote: Does anybody know more about this security flaw in the open-source Linux GNU C Library http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1 I updated a system of mine that was using an old version of glibc and rebooted. I can't do a full emerge world there or use various other portage tools due to the peculiarities of my current situation. Could I still be vulnerable? Your system may be vulnerable to this issue only if you have packages statically linked with vulnerable glibc libs, so most likely — no. But your system may be affected by a plenty of other issues in various packages. At the very least you should apply all GLSAs to your system: while they don't encompass all vulnerabilities, they should warn you about most common and important ones. Best regards, Andrew Savchenko pgpMWQmbZaBhp.pgp Description: PGP signature
Re: [gentoo-user] Re: [SOLVED] Regular user unable to use sound/alsa after upgrade
On 29/01/2015 20:11, Walter Dnes wrote: On Thu, Jan 29, 2015 at 12:52:58PM -0500, cov...@ccs.covici.com wrote I would check the permissions of /dev/dsp and /dev/snd maybe they should be world rw or something. The /var/tmp is just what the source directory is, don't worry about that. No /dev/dsp on my system. As for /dev/snd [d531][waltdnes][~] ll /dev/snd total 0 drwxr-xr-x 2 root root 160 Jan 28 21:50 . drwxr-xr-x 16 root root3400 Jan 29 02:50 .. crw-rw 1 root root 116, 2 Jan 28 21:50 controlC0 crw-rw 1 root root 116, 4 Jan 28 21:50 pcmC0D0c crw-rw 1 root root 116, 3 Jan 29 12:24 pcmC0D0p crw-rw 1 root root 116, 5 Jan 28 21:50 pcmC0D2c crw-rw 1 root root 116, 1 Jan 28 21:50 seq crw-rw 1 root root 116, 33 Jan 28 21:50 timer I went in as root and changed the entire snd subdirectory to root:users [d531][waltdnes][~] ll /dev/snd total 0 drwxr-xr-x 2 root users 160 Jan 28 21:50 . drwxr-xr-x 16 root root 3400 Jan 29 02:50 .. crw-rw 1 root users 116, 2 Jan 28 21:50 controlC0 crw-rw 1 root users 116, 4 Jan 28 21:50 pcmC0D0c crw-rw 1 root users 116, 3 Jan 29 13:05 pcmC0D0p crw-rw 1 root users 116, 5 Jan 28 21:50 pcmC0D2c crw-rw 1 root users 116, 1 Jan 28 21:50 seq crw-rw 1 root users 116, 33 Jan 28 21:50 timer ...and now sound works fine as regular user. Thank you very much for the solution. Check your udev rules. Those nodes will probably revert back to root:root on each reboot -- Alan McKinnon alan.mckin...@gmail.com
Re: [gentoo-user] iscsitarget or targetcli?
On Thursday, January 29, 2015 02:23:14 PM Andrea Conti wrote: What is the difference between the kernel-stuff (targetcli is only the config- tool) and scst? http://scst.sourceforge.net/comparison.html It was written by the SCST team, so it should be taken with a grain of salt; it is nonetheless a useful overview of the alternatives out there. andrea I found a few comparisons like that. I would prefer one from an independent source as both SCST and linux-iscsi.org (which seems to promote LIO/targetcli) both paint the picture theirs is stable and the other one might be -- Joost
Re: [gentoo-user] iscsitarget or targetcli?
On Thursday, January 29, 2015 02:18:13 PM Andrea Conti wrote: On 29/01/15 11:25, J. Roeleveld wrote: Hi all, I want to set up an iSCSI server (target in iSCSI terminology) running on Gentoo. Does anyone know which of the following 2 are better: - sys-block/iscsitarget - sys-block/targetcli Both don't seem to have had an update for over 2 years, but targetcli seems to be just the config-tool for whatever is in current kernels where, I think, iscsitarget is a userspace daemon? Many thanks, Joost Hi, sys-block/iscsitarget is composed of a kernel module and a userspace daemon, both compiled and installed by the ebuild. That's what I thought as well. LIO / targetcli does seem to work and is implemented into the Linux kernel. Is there anyone with actual experience with this together with Gentoo? As I said, my initial quick tests showed that it works the way I want it to. I would second the recommendation for SCST, which is actively developed and in my experience is quite more stable and tends to recover better from unexpected events than sys-block/iscsitarget (I have used both for quite some time). The only downside of SCST is that it requires a bit more work to install, mainly because there is no ebuild for it; moreover, while it can be built against and run on a stock kernel, it comes with a couple of kernel patches which should be applied for optimal performance or are needed fot specific features (e.g. the vdisk backend). I had a look at it, but the howtos I find are all based on older kernels (2.6.x). I am currently using 3.14.27 for my testing as ZFS requires a kernel older then 3.16. I am reluctant to apply kernel patches, would prefer just some modules. The documentation for installing SCST is scarcer then for LIO/targetcli. (The latter has recent documentation on the Arch-linux site) -- Joost
Re: [gentoo-user] Ghost cyber threat
Does anybody know more about this security flaw in the open-source Linux GNU C Library http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1 I updated a system of mine that was using an old version of glibc and rebooted. I can't do a full emerge world there or use various other portage tools due to the peculiarities of my current situation. Could I still be vulnerable? Your system may be vulnerable to this issue only if you have packages statically linked with vulnerable glibc libs, so most likely — no. But your system may be affected by a plenty of other issues in various packages. At the very least you should apply all GLSAs to your system: while they don't encompass all vulnerabilities, they should warn you about most common and important ones. I don't think I have USE=static anywhere. Any way to confirm? I've been watching glsa.gentoo.org (a little dismayed that this glibc vulnerability isn't there yet) but you prompted me to give glsa-check a try. It's telling me I'm vulnerable to some that I clearly am not vulnerable to. Do I need to clear a cache somewhere? - Grant
Re: [gentoo-user] Re: [SOLVED] Regular user unable to use sound/alsa after upgrade
On Thu, Jan 29, 2015 at 08:36:53PM +0200, Alan McKinnon wrote Check your udev rules. Those nodes will probably revert back to root:root on each reboot I use mdev https://wiki.gentoo.org/wiki/Mdev but that should not be a problem. My /etc/mdev.conf has... # alsa sound devices and audio stuff pcm.* root:audio 660 =snd/ control.* root:audio 660 =snd/ midi.*root:audio 660 =snd/ seq root:audio 660 =snd/ timer root:audio 660 =snd/ root:audio with permissions 660 should work for anybody in the audio group. Just for consistency, I manually changed it to... drwxr-xr-x 2 root audio 160 Jan 28 21:50 . drwxr-xr-x 16 root root 3400 Jan 29 02:50 .. crw-rw 1 root audio 116, 2 Jan 28 21:50 controlC0 crw-rw 1 root audio 116, 4 Jan 28 21:50 pcmC0D0c crw-rw 1 root audio 116, 3 Jan 29 13:36 pcmC0D0p crw-rw 1 root audio 116, 5 Jan 28 21:50 pcmC0D2c crw-rw 1 root audio 116, 1 Jan 28 21:50 seq crw-rw 1 root audio 116, 33 Jan 28 21:50 timer If it reverts to root:root next boot, I'll post to the busybox list. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
Re: [gentoo-user] Question about flakey RAM
On Tue, 27 Jan 2015 15:28:11 -0800 walt wrote: Yesterday I installed 4GB more of RAM in this machine for a total of 8GB, and the machine soon began random segfaulting and even a kernel crash or two, so obviously I suspected the new RAM was faulty. I let memtest86+ run overnight and it found zero memory errors. Today I exchanged the new RAM anyway and got a different brand this time, and that fixed the problem. My question is why didn't memtest86+ find any errors? Could it be that the first RAM I bought was actually okay but this machine didn't like it for some reason? Both were DDR3/1333MHz, just from different manufacturers. As an addition to earlier posted comments: 1) memtest86+ has a bit fade test which is not enabled by default (at least for 4.x branch which is the latest in tree now), so you have to enable and run it manually. IIRC it is enabled by default in 5.x branch (bug pending in bugzilla). By the way 5.x have some additional tests which may find faults unknown to 4.x 2) The same frequency is not enough to guarantee memory banks compatibility. They may require different timings or, less probably, voltage. Some BIOS tuning may help here. 3) Memory may be (un)buffered, (un)registered, ecc/non-ecc. Many of these combinations are not compatible with each other. 4) In some rare cases even banks with the same parameters from different manufacturers are not compatible due to technological differences (this goes down to how logical circuits are implemented). Best regards, Andrew Savchenko pgpiXoHXB_nSL.pgp Description: PGP signature
[gentoo-user] xorg-server complains about xf86-video-fbdev
Why am I getting this error: (x11-base/xorg-server-1.15.2-r1:0/1.15.2::gentoo, ebuild scheduled for merge) pulled in by (no parents that aren't satisfied by other packages in this slot) (x11-base/xorg-server-1.15.0:0/1.15.0::gentoo, installed) pulled in by x11-base/xorg-server:0/1.15.0= required by (x11-drivers/xf86-video-fbdev-0.4.4:0/0::gentoo, installed) Is there a replacement for xf86-video-fbdev? -- Joseph
Re: [gentoo-user] xorg-server complains about xf86-video-fbdev
Am Donnerstag, 29.01.2015 um 12:54 schrieb Joseph syscon...@gmail.com: Is there a replacement for xf86-video-fbdev? I guess, that you don't need this driver at all, as long as you don't have a video adapter that isn't supported by any other device driver. Regards wabe
Re: [gentoo-user] Question about flakey RAM
Am 28.01.2015 um 00:28 schrieb walt: Yesterday I installed 4GB more of RAM in this machine for a total of 8GB, and the machine soon began random segfaulting and even a kernel crash or two, so obviously I suspected the new RAM was faulty. I let memtest86+ run overnight and it found zero memory errors. Today I exchanged the new RAM anyway and got a different brand this time, and that fixed the problem. My question is why didn't memtest86+ find any errors? Could it be that the first RAM I bought was actually okay but this machine didn't like it for some reason? Both were DDR3/1333MHz, just from different manufacturers. Since this was not mentioned yet: Maybe because the ram was not faulty at all. Maybe it really operated in the range of allowed tolerances - and those were never crossed with memtest as a very light system load. But with an OS booted, the CPU, graphics solution, harddisks all sucking power like mad, your mainboard or PSU might not be able to deliver as stable currents as the specifications demand. Some memory is more tolerant than other.
[gentoo-user] Flash and cpu_flags_x86_sse2
Getting the following on updating world: !!! The ebuild selected to satisfy www-plugins/adobe-flash has unmet requirements. - www-plugins/adobe-flash-11.2.202.440::gentoo USE=kde -debug (-selinux) CPU_FLAGS_X86=-sse2 The following REQUIRED_USE flag constraints are unsatisfied: cpu_flags_x86_sse2 The above constraints are a subset of the following complete expression: cpu_flags_x86_sse2 debug? ( abi_x86_32 ) any-of ( abi_x86_64 abi_x86_32 ) Use flag sse2 is set, verified by both euse and a manual examination of make.conf. What am I missing? -- each generation wastes a little more of the future with greed and lust for riches - archie the cockroach [Don Marquis]
Re: [gentoo-user] Question about flakey RAM
On Thursday 29 Jan 2015 22:13:28 Volker Armin Hemmann wrote: Am 28.01.2015 um 00:28 schrieb walt: Yesterday I installed 4GB more of RAM in this machine for a total of 8GB, and the machine soon began random segfaulting and even a kernel crash or two, so obviously I suspected the new RAM was faulty. I let memtest86+ run overnight and it found zero memory errors. Today I exchanged the new RAM anyway and got a different brand this time, and that fixed the problem. My question is why didn't memtest86+ find any errors? Could it be that the first RAM I bought was actually okay but this machine didn't like it for some reason? Both were DDR3/1333MHz, just from different manufacturers. Since this was not mentioned yet: Maybe because the ram was not faulty at all. Maybe it really operated in the range of allowed tolerances - and those were never crossed with memtest as a very light system load. But with an OS booted, the CPU, graphics solution, harddisks all sucking power like mad, your mainboard or PSU might not be able to deliver as stable currents as the specifications demand. Some memory is more tolerant than other. Yes, I've witnessed this too after adding 2 new memory modules of a different size to the originals and from a different manufacturer, in a box with a suspect PSU. Memtest+86 was not erroring out, but the system was crashing when put under pressure. Typically I would get errors when more than the size of the old memory started being used. This got worse over time, as the PSU components were ageing. Eventually I replaced a capacitor in the PSU and the memory problems disappeared. It has been already mentioned, but it is worth noting that some BIOS/MoBos are more sensitive to different brands of memory. In those cases I found that using the same make and size modules resolves the problems. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] updating netbook : Python needs libjpeg.so.8 : solved
150129 Andrew Savchenko wrote: On Thu, 29 Jan 2015 05:52:27 -0500 Philip Webb wrote: The 3rd stumble was Python, which refused to compile, as it couldn't find /usr/lib/libjpeg.so.8 . It seems that Libjpeg-turbo works only on 64-bit systems that 32-bit systems like my netbook have to use simple Jpeg. No. libjpeg-turbo works fine here on ~x86. So does your Libjpeg-turbo install /usr/lib/libjpeg.so.8 or does your Python look for a different library or is the Python you refer to 3.x rather than 2.7 ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] Ghost cyber threat
Does anybody know more about this security flaw in the open-source Linux GNU C Library http://www.theglobeandmail.com/technology/linux-makers-release-patch-to-thwart-new-ghost-cyber-threat/article22662060/?cmpid=rss1 I updated a system of mine that was using an old version of glibc and rebooted. I can't do a full emerge world there or use various other portage tools due to the peculiarities of my current situation. Could I still be vulnerable? Your system may be vulnerable to this issue only if you have packages statically linked with vulnerable glibc libs, so most likely — no. But your system may be affected by a plenty of other issues in various packages. At the very least you should apply all GLSAs to your system: while they don't encompass all vulnerabilities, they should warn you about most common and important ones. I don't think I have USE=static anywhere. Any way to confirm? I've been watching glsa.gentoo.org (a little dismayed that this glibc vulnerability isn't there yet) but you prompted me to give glsa-check a try. It's telling me I'm vulnerable to some that I clearly am not vulnerable to. Do I need to clear a cache somewhere? glsa-check is working fine, it was a slotted issue. Still curious about a way to check for statically linked packages. - Grant
[gentoo-user] [SOLVED] Regular user unable to use sound/alsa after upgrade
On Thu, Jan 29, 2015 at 02:07:37PM -0500, Walter Dnes wrote If it reverts to root:root next boot, I'll post to the busybox list. It did... and I did. Before doing that, I did a bit of digging. Last night, I ran an update to catch the latest Adobe Flash security update. Along the way, busybox was upgraded from 1.23.0 to 1.23.0-r1. busybox 1.23.0 is no longer in the Gentoo tree. I reverted to 1.22.1, rebooted, and /dev/snd came up properly as root:audio. I've posted a message to the busybox list to let them know of the problem. -- Walter Dnes waltd...@waltdnes.org I don't run desktop environments; I run useful applications
[gentoo-user] Re: grub - gummiboot: good
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 01/28/2015 06:08 PM, Stefan G. Weichinger wrote: On 28.01.2015 23:51, Tom H wrote: Why two EFIs? One of them's unnecessary but if you want to have both, you have to have them both in the efibootmgr invocation. I don't know why. What I did: cd /boot rm -fr * gummiboot install grub2-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub_uefi --recheck (and maybe run kerninst to actually put a kernel and its initrd there) The grub2-install-command was just taken from shell history. It might be *wrong* ... yes. At least it says it runs without errors. When I run: # grub2-install --target=x86_64-efi --bootloader-id=grub_3 --recheck Installing for x86_64-efi platform. grub2-install: error: cannot find EFI directory. Can you create an entry for your kernel in 40_custom and test it? Take a look at grub.cfg. I doubt that grub-mkconfig looks for a kernel in '/boot/machine_id/kernel_version/' or that it recognizes 'kernel' and 'initrd' as valid names for a kernel and an initramfs. grub2-mkconfig did not detect any kernel, yes. That doesn't matter btw ... the reason to have grub2 in parallel is just the feature to boot iso-files (rescue media ...). All this additional grub2-fiddlery is basically learning how to make it work and getting the convenience of not having to insert a CD now and then. For daily work I am perfectly happy with gummiboot *just* booting my kernel(s) ... which works already! thanks, regards, Stefan (leaving now ... late here as mentioned) You have mounted your ESP on /boot, so you need to tell grub *that* is your ESP, not /boot/efi, like so: # grub2-install --target=x86_64-efi --efi-directory=/boot Once you do that, everything should pretty much Just Work. - -- Jonathan Callen -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCgAGBQJUyt+NAAoJEEIQbvYRB3mgolYP/1g9YlZ/IYaLlKNFOMiEKaIa KrsF+ne2vmITUXtLsVtwCDZNIQyHj6c/Ma7zHpm9Kbzn2OxpKt8dduDNdpA8QLwx E3TM3pV0AfCYRDazH6pZmHRpDc7gVTtz4yQA/uGJyyFynwqJ3LlPYqMzTv6zFUrf lJSBBHuNBU340xAukPf6iEMrNh5CbdT9bzzJGyEPfsGcAM3kDO0DlQC1jf8hgCwr YJsH/WB+EBJ4TR4phzYvAdGOJF04PAwtqTkBjmbyjTwNYy1oaZILu5qjEaHuA+PH Eybba4Dj3/ItIEyG8cy0Qw7fjUXby01OAYtnLUXMhBH7lxSsBFzcSvihxv3bpt+u HvHiOi3M+jWYpfhF1rUEGcK3pF8X7gDiQTaDkERzv+EcDLHG19McZPDb3Gpva6qi oot3O+ky5MQLuG9euhavalEMm2mDCQmSMkS7gVQff5tGUCeUc5fzLKXd1Sywj4Ze tSBctEU1gMpHenl0XO2FJ7OdgkAAeMYKSBkJJhLhYg8iXe7oBC09VmQeoPBvuwAR IMzOYJkD6+FY8pOdXQujRWnM47H9/r0434B+2nLujPQ1fgc/MHpVrv7LGwFMEocU 3UloQH4Mh927WNa/F9ilBwl5R0b8vh2hhymj8VENZmsPPB6hV5ZSsvGQ6somL+/r 4ULEtTdoNWUrIVVUvMjF =IoH5 -END PGP SIGNATURE-
Re: [gentoo-user] Ghost cyber threat
On Thu, Jan 29, 2015 at 7:53 PM, Grant emailgr...@gmail.com wrote: glsa-check is working fine, it was a slotted issue. Still curious about a way to check for statically linked packages. False positives in glsa data aren't unheard of - log those as bugs - vulnerable versions should be masked, and non-vulnerable versions shouldn't be flagged. So, if an unmasked package is flagged, there is a bug of some kind that should be fixed. Glsa's aren't sent out right now until the last arch is stable. -- Rich
Re: [gentoo-user] updating netbook : Python needs libjpeg.so.8 : solved
On Thu, 29 Jan 2015 18:13:35 -0500 Philip Webb wrote: 150129 Andrew Savchenko wrote: On Thu, 29 Jan 2015 05:52:27 -0500 Philip Webb wrote: The 3rd stumble was Python, which refused to compile, as it couldn't find /usr/lib/libjpeg.so.8 . It seems that Libjpeg-turbo works only on 64-bit systems that 32-bit systems like my netbook have to use simple Jpeg. No. libjpeg-turbo works fine here on ~x86. So does your Libjpeg-turbo install /usr/lib/libjpeg.so.8 or does your Python look for a different library or is the Python you refer to 3.x rather than 2.7 ? I don't have libjpeg.so.8 on my system at all. Al for python, I have 2.7.8, 3.3.5-r1 and 3.4.2 installed. If during compilation package requires libjpeg.so.8 from you, you should fix pkg-config file(s) or rebuild an appropriate package(s). Best regards, Andrew Savchenko pgpb5wjMEr2oD.pgp Description: PGP signature
Re: [gentoo-user] Flash and cpu_flags_x86_sse2
On Thu, 29 Jan 2015 19:46:57 -0500 ddjones ddjo...@riddlemaster.org wrote: Getting the following on updating world: !!! The ebuild selected to satisfy www-plugins/adobe-flash has unmet requirements. - www-plugins/adobe-flash-11.2.202.440::gentoo USE=kde -debug (-selinux) CPU_FLAGS_X86=-sse2 The following REQUIRED_USE flag constraints are unsatisfied: cpu_flags_x86_sse2 The above constraints are a subset of the following complete expression: cpu_flags_x86_sse2 debug? ( abi_x86_32 ) any-of ( abi_x86_64 abi_x86_32 ) Use flag sse2 is set, verified by both euse and a manual examination of make.conf. What am I missing? eselect news list
Re: [gentoo-user] Ghost cyber threat
On Thu, 29 Jan 2015 16:53:43 -0800 Grant wrote: glsa-check is working fine, it was a slotted issue. Still curious about a way to check for statically linked packages. There is no simple solution for this... USE flags static and static-libs handle cases where there is a choice between static and non-static version. In theory it is possible that some package (like boot loader helper) can be linked only statically, thus you will not be able to find it by USE flag. Though probability of this is very low, and due to a special nature of such binaries (or libraries) attack surface is even less. So you may assume your system reasonable secure if: - all GLSAs are applied; - there are no preserved libraries left (all packages using vulnerable libs must be rebuilt); - all static binaries and libraries depending directly or indirectly on vulnerable packages are rebuild; - there are no running processes using deleted files (reboot is a brute, but effective way to do this, otherwise one should grep lsof -n output for (deleted) files in use). - kernel should be updated to the latest version in branch if it is still supported, or upgrade to another branch, preferably LTS, if it is EOLed already. I have not seen GLSAs for kernel in ages, though old kernels definitely have serious security issues, and they may be far more serious than Ghost glibc bug. Best regards, Andrew Savchenko pgpgafG4_tW6U.pgp Description: PGP signature
Re: [gentoo-user] updating netbook : Python needs libjpeg.so.8 : solved
150130 Andrew Savchenko wrote: On Thu, 29 Jan 2015 18:13:35 -0500 Philip Webb wrote: PW The 3rd stumble was Python, which refused to compile, as it couldn't find /usr/lib/libjpeg.so.8 . It seems that Libjpeg-turbo works only on 64-bit systems that 32-bit systems like my netbook have to use simple Jpeg. AS No. libjpeg-turbo works fine here on ~x86. PW So does your Libjpeg-turbo install /usr/lib/libjpeg.so.8 or does your Python look for a different library or is the Python you refer to 3.x rather than 2.7 ? AS I don't have libjpeg.so.8 on my system at all. As for python, I have 2.7.8, 3.3.5-r1 and 3.4.2 installed. If during compilation package requires libjpeg.so.8 from you, you should fix pkg-config file(s) or rebuild an appropriate package(s). On my netbook, Python-2.7.9-r1 won't compile without libjpeg.so.8 . How do I tell Python it needs the library installed by Libjpeg-turbo, which is libjpeg.so.62 ? -- ,, SUPPORT ___//___, Philip Webb ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto TRANSIT`-O--O---' purslowatchassdotutorontodotca
Re: [gentoo-user] [SOLVED] Regular user unable to use sound/alsa after upgrade
On Thursday 29 Jan 2015 23:14:34 Walter Dnes wrote: On Thu, Jan 29, 2015 at 02:07:37PM -0500, Walter Dnes wrote If it reverts to root:root next boot, I'll post to the busybox list. It did... and I did. Before doing that, I did a bit of digging. Last night, I ran an update to catch the latest Adobe Flash security update. Along the way, busybox was upgraded from 1.23.0 to 1.23.0-r1. busybox 1.23.0 is no longer in the Gentoo tree. I reverted to 1.22.1, rebooted, and /dev/snd came up properly as root:audio. I've posted a message to the busybox list to let them know of the problem. Here the access rights and ownership look like this: $ ls -al /dev/snd total 0 drwxr-xr-x 3 root root 260 Jan 30 06:14 . drwxr-xr-x 15 root root 5080 Jan 30 06:14 .. drwxr-xr-x 2 root root 80 Jan 30 06:14 by-path crw-rw+ 1 root audio 116, 5 Jan 30 06:14 controlC0 crw-rw+ 1 root audio 116, 2 Jan 30 06:14 controlC1 crw-rw+ 1 root audio 116, 9 Jan 30 06:14 hwC0D0 crw-rw+ 1 root audio 116, 4 Jan 30 06:14 hwC1D0 crw-rw+ 1 root audio 116, 7 Jan 30 06:19 pcmC0D0c crw-rw+ 1 root audio 116, 6 Jan 30 06:31 pcmC0D0p crw-rw+ 1 root audio 116, 8 Jan 30 06:14 pcmC0D2c crw-rw+ 1 root audio 116, 3 Jan 30 06:19 pcmC1D3p crw-rw 1 root audio 116, 1 Jan 30 06:14 seq crw-rw+ 1 root audio 116, 33 Jan 30 06:14 timer -- Regards, Mick signature.asc Description: This is a digitally signed message part.
Re: [gentoo-user] Flash and cpu_flags_x86_sse2
On Thu, 29 Jan 2015 19:46:57 -0500, ddjones wrote: The above constraints are a subset of the following complete expression: cpu_flags_x86_sse2 debug? ( abi_x86_32 ) any-of ( abi_x86_64 abi_x86_32 ) Use flag sse2 is set, verified by both euse and a manual examination of make.conf. What am I missing? CPU specific USE flags have moved, there was a news item about it eselect news read -- Neil Bothwick A man needs a mistress - just to break the monogamy pgp7EXmocFw5j.pgp Description: OpenPGP digital signature
