Discuss

discuss@lists.centos.org

34753 discussions

odd automount issue
by m.roth＠5-cent.us 04 Feb '14

04 Feb '14

We're seeing, in the log, automount trying (and failing) to mount a few directories NFS in the middle of the night. For example: 03:49:50 <my own workstation> automount[7872]: key "httpd" not found in map source(s) It doesn't seem to be triggered by the pen testers, nor by logs (I think), so we're all at a loss to guess what's triggering this. Anyone have any thoughts on it? Most of our systems are 6.5, btw. mark

1 1

Re: [CentOS] Experience with BTRFS?
by Fernando Cassia 04 Feb '14

04 Feb '14

On Tue, Feb 4, 2014 at 5:44 PM, Reindl Harald <h.reindl(a)thelounge.net>wrote: > 3.14 does not matter at all in context of RHEL > 2.6.32-431.3.1.el6.x86_64 is not a pure 2.6.32 kernel > I understand that but since Oracle Linux is a RHEL derivative like CentOS ... I wanted to mention the OL Playground repo... It doesn´t currently have kernel 3.14, the newest one is 3.13 at the moment, but will eventually get it. http://public-yum.oracle.com/repo/OracleLinux/OL6/playground/latest/x86_64/… http://public-yum.oracle.com/repo/OracleLinux/OL6/playground/latest/x86_64/… Maybe you can test it on a VM under CentOS... FC -- During times of Universal Deceit, telling the truth becomes a revolutionary act Durante épocas de Engaño Universal, decir la verdad se convierte en un Acto Revolucionario - George Orwell

1 0

I want to ask about some Kernel level operations.
by Eliezer Croitoru 04 Feb '14

04 Feb '14

I want to make sure that while compiling as root nothing will break down inside the machine. I want to compile software on a Xeon SERVER. The basic issue is that there is a recommendation to not compile it as a root user. I have compiled software as a root user more then once and I am not sure why would there is a need to run it as non-root user? I have taken a look at the /proc/ FS but I do not see anything that can harm anything yet. From my aspect it's just background of electricity noise. I will be happy to hear from experience of others about it. Thanks, Eliezer

7 14

[OT] ssh and security DVR
by m.roth＠5-cent.us 04 Feb '14

04 Feb '14

Does anyone have any "security appliance" DVR, and can you a) telnet or b) ssh into it? Also, I have read that on a lot of the low-end ones, like Swann, port 9000 is completely open, but it's not clear to me from the hack post <http://console-cowboys.blogspot.com/2013/01/swann-song-dvr-insecurity.html> whether I could ssh in there, or rsync from a server through that port. mark

1 0

Memory leak - how to investigate
by Jussi Hirvi 04 Feb '14

04 Feb '14

My web & name server runs out of memory from time to time, to the point where it's completely unresponsive to anything. At that point reset is the only alternative. (Or, as this is a virtual guest, I just say "virsh destroy"). But why this happens - I would like to know. The host in question is a KVM guest, and runs CentOS 6.4. From "top" (situation now): Mem: 1361564k total, 1264324k used, 97240k free, 8428k buffers Swap: 3014648k total, 64852k used, 2949796k free, 358676k cached At or before the last crash I got a long error message on the console. "Oom-killer" was called repeatedly by httpd and named. I paste below the first error message, which is long. There were several long entries like this. I - Jussi [root@ns1 ~]# httpd invoked oom-killer: gfp_mask=0x280da, order=0, oom_adj=0, oom_score_adj=0 httpd cpuset=/ mems_allowed=0 Pid: 2962, comm: httpd Not tainted 2.6.32-358.23.2.el6.x86_64 #1 Call Trace: [<ffffffff810cb641>] ? cpuset_print_task_mems_allowed+0x91/0xb0 [<ffffffff8111ce40>] ? dump_header+0x90/0x1b0 [<ffffffff810e930e>] ? __delayacct_freepages_end+0x2e/0x30 [<ffffffff8121d4ec>] ? security_real_capable_noaudit+0x3c/0x70 [<ffffffff8111d2c2>] ? oom_kill_process+0x82/0x2a0 [<ffffffff8111d201>] ? select_bad_process+0xe1/0x120 [<ffffffff8111d700>] ? out_of_memory+0x220/0x3c0 [<ffffffff8112c3dc>] ? __alloc_pages_nodemask+0x8ac/0x8d0 [<ffffffff81160d6a>] ? alloc_pages_vma+0x9a/0x150 [<ffffffff81143f0b>] ? handle_pte_fault+0x76b/0xb50 [<ffffffffa00c60f9>] ? ext4_check_acl+0x29/0x90 [ext4] [<ffffffff81075887>] ? current_fs_time+0x27/0x30 [<ffffffff8114452a>] ? handle_mm_fault+0x23a/0x310 [<ffffffff810474e9>] ? __do_page_fault+0x139/0x480 [<ffffffff8114aaba>] ? do_mmap_pgoff+0x33a/0x380 [<ffffffff81513bfe>] ? do_page_fault+0x3e/0xa0 [<ffffffff81510fb5>] ? page_fault+0x25/0x30 Mem-Info: Node 0 DMA per-cpu: CPU 0: hi: 0, btch: 1 usd: 0 Node 0 DMA32 per-cpu: CPU 0: hi: 186, btch: 31 usd: 89 active_anon:201535 inactive_anon:68173 isolated_anon:3424 active_file:130 inactive_file:284 isolated_file:160 unevictable:0 dirty:0 writeback:245 unstable:0 free:14234 slab_reclaimable:2891 slab_unreclaimable:13218 mapped:239 shmem:14 pagetables:28858 bounce:0 Node 0 DMA free:8252kB min:340kB low:424kB high:508kB active_anon:2168kB inactive_anon:4624kB active_file:4kB inactive_file:144kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15348kB mlocked:0kB dirty:0kB writeback:28kB mapped:8kB shmem:0kB slab_reclaimable:12kB slab_unreclaimable:128kB kernel_stack:8kB pagetables:376kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1424 all_unreclaimable? no lowmem_reserve[]: 0 1956 1956 1956 Node 0 DMA32 free:48684kB min:44712kB low:55888kB high:67068kB active_anon:803972kB inactive_anon:268068kB active_file:516kB inactive_file:992kB unevictable:0kB isolated(anon):13696kB isolated(file):640kB present:2003828kB mlocked:0kB dirty:0kB writeback:888kB mapped:948kB shmem:56kB slab_reclaimable:11552kB slab_unreclaimable:52744kB kernel_stack:3344kB pagetables:115056kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:7552 all_unreclaimable? no lowmem_reserve[]: 0 0 0 0 Node 0 DMA: 25*4kB 11*8kB 6*16kB 3*32kB 9*64kB 3*128kB 1*256kB 3*512kB 1*1024kB 2*2048kB 0*4096kB = 8252kB Node 0 DMA32: 977*4kB 401*8kB 320*16kB 179*32kB 58*64kB 63*128kB 32*256kB 7*512kB 3*1024kB 0*2048kB 1*4096kB = 48684kB 21463 total pagecache pages 20882 pages in swap cache Swap cache stats: add 1523887, delete 1503005, find 201987/297332 Free swap = 0kB Total swap = 3014648kB 511996 pages RAM 43605 pages reserved 66036 pages shared 446256 pages non-shared [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name [ 449] 0 449 2675 0 0 -17 -1000 udevd [ 1080] 0 1080 6909 6 0 -17 -1000 auditd [ 1105] 0 1105 62271 1 0 0 0 rsyslogd [ 1142] 25 1142 40455 262 0 0 0 named [ 1184] 0 1184 16563 0 0 -17 -1000 sshd [ 1195] 0 1195 13036 0 0 0 0 vsftpd [ 1231] 0 1231 27041 1 0 0 0 mysqld_safe [ 1333] 27 1333 187111 4825 0 0 0 mysqld [ 1430] 0 1430 20216 21 0 0 0 master [ 1438] 89 1438 20236 18 0 0 0 pickup [ 1439] 89 1439 20279 22 0 0 0 qmgr [ 1440] 0 1440 79250 368 0 0 0 httpd [ 1448] 0 1448 29313 34 0 0 0 crond [ 1459] 48 1459 88738 727 0 0 0 httpd [ 1460] 48 1460 89244 494 0 0 0 httpd [ 1461] 48 1461 89729 803 0 0 0 httpd [ 1462] 48 1462 88987 1055 0 0 0 httpd [ 1463] 48 1463 89796 2560 0 0 0 httpd [ 1464] 48 1464 91371 3558 0 0 0 httpd [ 1465] 48 1465 88596 1283 0 0 0 httpd [ 1466] 48 1466 90794 1253 0 0 0 httpd [ 1469] 0 1469 106619 198 0 0 0 fail2ban-server [ 1497] 0 1497 1015 1 0 0 0 mingetty [ 1499] 0 1499 1015 1 0 0 0 mingetty [ 1501] 0 1501 1015 1 0 0 0 mingetty [ 1503] 0 1503 1015 1 0 0 0 mingetty [ 1505] 0 1505 1015 1 0 0 0 mingetty [ 1507] 0 1507 1015 1 0 0 0 mingetty [ 1512] 0 1512 2674 0 0 -17 -1000 udevd [ 1513] 0 1513 2674 0 0 -17 -1000 udevd [ 1514] 0 1514 14249 1 0 0 0 login [ 1520] 48 1520 89586 1139 0 0 0 httpd [ 1522] 48 1522 90606 773 0 0 0 httpd [ 1523] 48 1523 88343 2527 0 0 0 httpd [ 1524] 0 1524 27075 1 0 0 0 bash [ 1549] 48 1549 88937 1738 0 0 0 httpd [ 1550] 48 1550 89721 1736 0 0 0 httpd [ 1579] 48 1579 91106 600 0 0 0 httpd [ 1581] 48 1581 88218 1491 0 0 0 httpd [ 1582] 48 1582 88559 595 0 0 0 httpd [ 1755] 48 1755 88115 1716 0 0 0 httpd [ 2376] 48 2376 90860 1318 0 0 0 httpd [ 2562] 48 2562 89680 2348 0 0 0 httpd [ 2697] 48 2697 87846 2082 0 0 0 httpd [ 2709] 48 2709 86589 3201 0 0 0 httpd [ 2710] 48 2710 86056 2467 0 0 0 httpd [ 2713] 48 2713 84422 1068 0 0 0 httpd [ 2714] 48 2714 85544 2688 0 0 0 httpd [ 2715] 48 2715 84748 1505 0 0 0 httpd [ 2716] 48 2716 84569 1318 0 0 0 httpd [ 2721] 48 2721 84815 1718 0 0 0 httpd [ 2722] 48 2722 84502 1256 0 0 0 httpd [ 2723] 48 2723 87014 4123 0 0 0 httpd [ 2724] 48 2724 84502 1246 0 0 0 httpd [ 2725] 48 2725 84420 1203 0 0 0 httpd [ 2726] 48 2726 86782 4034 0 0 0 httpd [ 2727] 48 2727 84502 1262 0 0 0 httpd [ 2728] 48 2728 86054 2340 0 0 0 httpd [ 2737] 48 2737 84815 1743 0 0 0 httpd [ 2738] 48 2738 84748 1639 0 0 0 httpd [ 2739] 48 2739 86589 3300 0 0 0 httpd [ 2740] 48 2740 85202 2201 0 0 0 httpd [ 2741] 48 2741 86054 1742 0 0 0 httpd [ 2742] 48 2742 87014 4231 0 0 0 httpd [ 2743] 48 2743 84301 711 0 0 0 httpd [ 2744] 48 2744 84502 1233 0 0 0 httpd [ 2745] 48 2745 84815 1614 0 0 0 httpd [ 2746] 48 2746 84420 1113 0 0 0 httpd [ 2747] 48 2747 84432 913 0 0 0 httpd [ 2748] 48 2748 84301 724 0 0 0 httpd [ 2749] 48 2749 86251 3541 0 0 0 httpd [ 2750] 48 2750 84301 764 0 0 0 httpd [ 2751] 48 2751 84422 1004 0 0 0 httpd [ 2752] 48 2752 84291 588 0 0 0 httpd [ 2758] 48 2758 84301 687 0 0 0 httpd [ 2759] 48 2759 84301 725 0 0 0 httpd [ 2760] 48 2760 84432 890 0 0 0 httpd [ 2761] 48 2761 84301 788 0 0 0 httpd [ 2765] 48 2765 84420 930 0 0 0 httpd [ 2766] 48 2766 84430 868 0 0 0 httpd [ 2769] 48 2769 84432 946 0 0 0 httpd [ 2770] 48 2770 87526 8319 0 0 0 httpd [ 2774] 48 2774 84291 582 0 0 0 httpd [ 2775] 48 2775 84430 897 0 0 0 httpd [ 2779] 48 2779 84301 692 0 0 0 httpd [ 2780] 48 2780 84301 659 0 0 0 httpd [ 2781] 48 2781 84430 1098 0 0 0 httpd [ 2782] 48 2782 84420 2692 0 0 0 httpd [ 2783] 48 2783 84430 823 0 0 0 httpd [ 2784] 48 2784 84422 1062 0 0 0 httpd [ 2785] 48 2785 84432 899 0 0 0 httpd [ 2786] 48 2786 84502 1259 0 0 0 httpd [ 2787] 48 2787 84301 733 0 0 0 httpd [ 2788] 48 2788 84434 906 0 0 0 httpd [ 2789] 48 2789 84432 1000 0 0 0 httpd [ 2790] 48 2790 87526 8311 0 0 0 httpd [ 2791] 48 2791 84430 1067 0 0 0 httpd [ 2792] 48 2792 84504 1259 0 0 0 httpd [ 2793] 48 2793 84301 749 0 0 0 httpd [ 2794] 48 2794 84422 935 0 0 0 httpd [ 2795] 48 2795 84303 740 0 0 0 httpd [ 2796] 48 2796 84560 1417 0 0 0 httpd [ 2797] 48 2797 84420 1091 0 0 0 httpd [ 2798] 48 2798 84420 1023 0 0 0 httpd [ 2799] 48 2799 84301 678 0 0 0 httpd [ 2800] 48 2800 84301 643 0 0 0 httpd [ 2809] 48 2809 84422 1017 0 0 0 httpd [ 2811] 48 2811 84301 643 0 0 0 httpd [ 2812] 48 2812 84301 620 0 0 0 httpd [ 2813] 48 2813 84432 958 0 0 0 httpd [ 2814] 48 2814 84432 928 0 0 0 httpd [ 2815] 48 2815 84420 1126 0 0 0 httpd [ 2816] 48 2816 87014 7940 0 0 0 httpd [ 2817] 48 2817 84301 725 0 0 0 httpd [ 2818] 48 2818 84301 695 0 0 0 httpd [ 2819] 48 2819 84432 800 0 0 0 httpd [ 2820] 48 2820 84420 1209 0 0 0 httpd [ 2821] 48 2821 84502 1351 0 0 0 httpd [ 2822] 48 2822 84815 1684 0 0 0 httpd [ 2823] 48 2823 84301 702 0 0 0 httpd [ 2824] 48 2824 84430 1416 0 0 0 httpd [ 2825] 48 2825 84432 824 0 0 0 httpd [ 2826] 48 2826 84432 899 0 0 0 httpd [ 2827] 48 2827 84432 884 0 0 0 httpd [ 2828] 48 2828 84301 794 0 0 0 httpd [ 2829] 48 2829 84301 723 0 0 0 httpd [ 2830] 48 2830 84301 1413 0 0 0 httpd [ 2831] 48 2831 85331 3528 0 0 0 httpd [ 2832] 48 2832 84420 3300 0 0 0 httpd [ 2833] 48 2833 84430 1353 0 0 0 httpd [ 2834] 48 2834 84432 897 0 0 0 httpd [ 2835] 48 2835 84291 572 0 0 0 httpd [ 2836] 48 2836 85460 3295 0 0 0 httpd [ 2852] 48 2852 83773 4497 0 0 0 httpd [ 2853] 48 2853 84814 2177 0 0 0 httpd [ 2857] 48 2857 84420 1140 0 0 0 httpd [ 2858] 48 2858 84432 925 0 0 0 httpd [ 2859] 48 2859 84485 1568 0 0 0 httpd [ 2860] 48 2860 84552 1749 0 0 0 httpd [ 2861] 48 2861 84291 582 0 0 0 httpd [ 2862] 48 2862 84420 3627 0 0 0 httpd [ 2868] 48 2868 84301 804 0 0 0 httpd [ 2869] 48 2869 84487 1268 0 0 0 httpd [ 2870] 48 2870 84301 803 0 0 0 httpd [ 2874] 48 2874 84422 1033 0 0 0 httpd [ 2875] 48 2875 84301 718 0 0 0 httpd [ 2876] 48 2876 84485 1125 0 0 0 httpd [ 2877] 48 2877 84420 924 0 0 0 httpd [ 2878] 48 2878 84748 2217 0 0 0 httpd [ 2885] 48 2885 84301 2638 0 0 0 httpd [ 2886] 48 2886 84420 905 0 0 0 httpd [ 2887] 48 2887 84420 1558 0 0 0 httpd [ 2888] 48 2888 84301 697 0 0 0 httpd [ 2889] 48 2889 84502 1228 0 0 0 httpd [ 2904] 48 2904 84430 791 0 0 0 httpd [ 2915] 48 2915 84748 1518 0 0 0 httpd [ 2916] 48 2916 85331 3691 0 0 0 httpd [ 2917] 48 2917 84569 1634 0 0 0 httpd [ 2918] 48 2918 84239 4498 0 0 0 httpd [ 2919] 48 2919 84502 2969 0 0 0 httpd [ 2920] 48 2920 86763 4460 0 0 0 httpd [ 2921] 48 2921 84420 1133 0 0 0 httpd [ 2922] 48 2922 86381 5779 0 0 0 httpd [ 2928] 48 2928 84502 2436 0 0 0 httpd [ 2938] 48 2938 85208 2426 0 0 0 httpd [ 2939] 48 2939 86055 5438 0 0 0 httpd [ 2940] 48 2940 84487 4186 0 0 0 httpd [ 2944] 48 2944 84432 2877 0 0 0 httpd [ 2945] 48 2945 84291 1446 0 0 0 httpd [ 2946] 48 2946 84818 3977 0 0 0 httpd [ 2960] 48 2960 84239 4311 0 0 0 httpd [ 2961] 48 2961 89636 9983 0 0 0 httpd [ 2962] 48 2962 87955 8183 0 0 0 httpd [ 2970] 48 2970 84241 4777 0 0 0 httpd [ 2973] 48 2973 84239 4759 0 0 0 httpd [ 2974] 48 2974 80053 1296 0 0 0 httpd [ 2975] 48 2975 80012 1410 0 0 0 httpd [ 2976] 48 2976 80185 1606 0 0 0 httpd [ 2978] 48 2978 79284 414 0 0 0 httpd [ 2980] 48 2980 80185 1387 0 0 0 httpd [ 2981] 48 2981 80021 1076 0 0 0 httpd [ 2982] 48 2982 80181 1383 0 0 0 httpd [ 2983] 48 2983 80138 1348 0 0 0 httpd [ 2984] 48 2984 80202 1273 0 0 0 httpd [ 2985] 48 2985 80010 418 0 0 0 httpd [ 2986] 48 2986 79990 1409 0 0 0 httpd [ 2988] 48 2988 80202 1540 0 0 0 httpd [ 2989] 48 2989 79996 756 0 0 0 httpd [ 2990] 48 2990 80010 1412 0 0 0 httpd [ 2991] 48 2991 79986 789 0 0 0 httpd [ 2992] 48 2992 79284 401 0 0 0 httpd [ 2993] 48 2993 80189 1562 0 0 0 httpd [ 2994] 48 2994 80119 1316 0 0 0 httpd [ 3010] 48 3010 79283 425 0 0 0 httpd [ 3013] 48 3013 80046 1291 0 0 0 httpd [ 3016] 48 3016 79250 412 0 0 0 httpd [ 3018] 48 3018 79283 451 0 0 0 httpd [ 3022] 0 3022 33480 63 0 0 0 crond Out of memory: Kill process 1333 (mysqld) score 12 or sacrifice child Killed process 1333, UID 27, (mysqld) total-vm:748444kB, anon-rss:19232kB, file-rss:68kB

9 16

CentOS-announce Digest, Vol 108, Issue 2
by centos-announce-request＠centos.org 04 Feb '14

04 Feb '14

Send CentOS-announce mailing list submissions to centos-announce(a)centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request(a)centos.org You can reach the person managing the list at centos-announce-owner(a)centos.org When replying, please edit your Subject line so it is more specific than "Re: Contents of CentOS-announce digest..." Today's Topics: 1. CESA-2014:0127 Moderate CentOS 6 librsvg2 Update (Johnny Hughes) 2. CESA-2014:0126 Moderate CentOS 6 openldap Update (Johnny Hughes) 3. CEBA-2014:0125 CentOS 6 tigervnc Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Tue, 4 Feb 2014 05:35:04 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2014:0127 Moderate CentOS 6 librsvg2 Update To: centos-announce(a)centos.org Message-ID: <20140204053504.GA49218(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2014:0127 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2014-0127.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 7f582307cabadd730387b49d93e454ab8e9007a98c991210ed3b86f67b9f29f9 librsvg2-2.26.0-6.el6_5.2.i686.rpm 4632e3a6c32f7e6979ea467548f33f24fa1bfb3ade3de46fb8377864346098bf librsvg2-devel-2.26.0-6.el6_5.2.i686.rpm x86_64: 7f582307cabadd730387b49d93e454ab8e9007a98c991210ed3b86f67b9f29f9 librsvg2-2.26.0-6.el6_5.2.i686.rpm 664950eb6b1cb297982ebf569a537b80c8c5605b01ab996dbfe41287a1aa553c librsvg2-2.26.0-6.el6_5.2.x86_64.rpm 4632e3a6c32f7e6979ea467548f33f24fa1bfb3ade3de46fb8377864346098bf librsvg2-devel-2.26.0-6.el6_5.2.i686.rpm d7e7d9a1a0ff23aa4807542f22960580d0e81571af316dc168acf077097e6171 librsvg2-devel-2.26.0-6.el6_5.2.x86_64.rpm Source: 59a805614f98312172e2a467079481f9eda8dc05d8438b1be852879e51b2a4d0 librsvg2-2.26.0-6.el6_5.2.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Tue, 4 Feb 2014 05:35:44 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CESA-2014:0126 Moderate CentOS 6 openldap Update To: centos-announce(a)centos.org Message-ID: <20140204053544.GA49526(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Security Advisory 2014:0126 Moderate Upstream details at : https://rhn.redhat.com/errata/RHSA-2014-0126.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 07c4f6e0049e9e53255b3effe63421d64d48de4eafc116b28c9b77c63a8e24ec openldap-2.4.23-34.el6_5.1.i686.rpm 26dde0c2324e45b0b7aad2eca7c018f5bc78e49465b96ce281ab729d9c0a71ab openldap-clients-2.4.23-34.el6_5.1.i686.rpm f4e3a08cb06c1c7442b176cabcd3f2dc3f9a2d7eaebae1cf0a927a2065ebad17 openldap-devel-2.4.23-34.el6_5.1.i686.rpm fe828f57493fb60f8fe5f9dcda25e2ed1980fdf1df42f3cefdcca68f2ff34a63 openldap-servers-2.4.23-34.el6_5.1.i686.rpm 500ae2b4280dd4f638524cfe24cc374232c5e4faca262a37dc3d3446e69a7b9a openldap-servers-sql-2.4.23-34.el6_5.1.i686.rpm x86_64: 07c4f6e0049e9e53255b3effe63421d64d48de4eafc116b28c9b77c63a8e24ec openldap-2.4.23-34.el6_5.1.i686.rpm 27cae8bc3e94267b8b319c6cb1d49ba556130d72a983aa6cd27b7289d47d2d42 openldap-2.4.23-34.el6_5.1.x86_64.rpm ca6194ef492b2e1c193c80d84f0103570c878e5a19007b631d21350cbeceb92d openldap-clients-2.4.23-34.el6_5.1.x86_64.rpm f4e3a08cb06c1c7442b176cabcd3f2dc3f9a2d7eaebae1cf0a927a2065ebad17 openldap-devel-2.4.23-34.el6_5.1.i686.rpm 44f458b7ddd91937668fc183dea40c6204a5837de35d26301d9a8c872fe4ca8e openldap-devel-2.4.23-34.el6_5.1.x86_64.rpm 42fe4524d0a74da980db54284b506b2a97a3753b6ba971c90694d5176aba5381 openldap-servers-2.4.23-34.el6_5.1.x86_64.rpm 915b474fe581b42c960562f078926899ba437333a78012610e85d6efbff16a15 openldap-servers-sql-2.4.23-34.el6_5.1.x86_64.rpm Source: 0260ef91950e6c640ab0399d17d22f7a6658916a8409f97f75f381710bbd8bd6 openldap-2.4.23-34.el6_5.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Tue, 4 Feb 2014 05:36:08 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2014:0125 CentOS 6 tigervnc Update To: centos-announce(a)centos.org Message-ID: <20140204053608.GA49772(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2014:0125 Upstream details at : https://rhn.redhat.com/errata/RHBA-2014-0125.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 11180f5ea56476c6a5a7dff53aeee0c3dc054346312950b9ed431aa38045097e tigervnc-1.1.0-8.el6_5.i686.rpm 12cd6349f8d16539b6580eaaffbfe59af7b26ca27083bfa5305290e299dbfb00 tigervnc-server-1.1.0-8.el6_5.i686.rpm 9b10dab6c2925c3ede850bf842580bbc4fe5f154325b477c3161fa7fd88893ef tigervnc-server-applet-1.1.0-8.el6_5.noarch.rpm e6f5988b2a2392f27e28beb3faadeaf4623cb1f2a7359fbbd45fee05ba8a2db2 tigervnc-server-module-1.1.0-8.el6_5.i686.rpm x86_64: e3baf476de9b2366f466419c798402537aa7f26b66658e7c334d9e3cb87d8a4f tigervnc-1.1.0-8.el6_5.x86_64.rpm 606bf9bdd96eac93db1bb17b7433a1d06ab4de53af6e2e9c62745b4598a525a8 tigervnc-server-1.1.0-8.el6_5.x86_64.rpm 9b10dab6c2925c3ede850bf842580bbc4fe5f154325b477c3161fa7fd88893ef tigervnc-server-applet-1.1.0-8.el6_5.noarch.rpm e971b66241ac9a736e0c2d2ab2db2f8ca4aa41cf1d28dc285a90771d9bb93c68 tigervnc-server-module-1.1.0-8.el6_5.x86_64.rpm Source: 1bc4aeb1d6878af61b4ae7544adc985a039467229db3cb2f767a9a54f8c94492 tigervnc-1.1.0-8.el6_5.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ _______________________________________________ CentOS-announce mailing list CentOS-announce(a)centos.org http://lists.centos.org/mailman/listinfo/centos-announce End of CentOS-announce Digest, Vol 108, Issue 2 ***********************************************

1 0

Re: [CentOS] Password hash rounds solved - important security implications
by george.shaffer＠comcast.net 04 Feb '14

04 Feb '14

A member of the scientific-linux-users(a)fnal.gov wrote: On 01/14/2014 04:19 PM, George Shaffer wrote: > > If anyone has gotten password hash rounds using hash_rounds_min and > > hash_rounds_max in libuser.conf, or the counter part in login.defs > > (SHA_CRYPT_MIN_ROUNDS, SHA_CRYPT_MAX_ROUNDS), to work on any RHEL related > > distribution, I would appreciate knowing how you did it, because this does > > not seem to work as the documentation I've found says it should. I know > > the crypt method must be SHA256 or SHA512. > > This has an additional PAM setting that might be pertinent. > http://blog.myconan.net/posts/3567 Thank you. This is just what I needed. The hash rounds control is now working, mostly. At the maximum rounds setting it took 14 to 19 seconds depending on which PC I was on. I needed to bring the delay down to around 1 to 2 seconds. It's not working as the documentation describes. With both libuser.conf and login.defs set to ranges of 900000000 to 999000000 and pam.d/password-auth-ac set to 900000000, the actual rounds on both SL and CentOS were 9999999 or < 1.1% of what it should have been. This doesn't matter to me, as I need it faster, not slower. In pam.d/ both password-auth and system-auth are links to password-auth-ac and system-auth-ac respectively. These files clearly state: # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. which is sometimes, but not always true. If a rounds number remains in both password-auth and system-auth after authconfig --updateall is run, that is the number which is used, except the maximum value is 9999999 and not 999999999. I got 1000000 to work on both SL 6.3 and CentOS 5.10, and authentication took just about 2 seconds on both systems. On CentOS 5.10 I could find no PAM documentation anywhere that described the rounds option; I had to rely entirely on the brief blog brought to my attention by the S-L-users list member. On SL 6.3 the PAM rounds option is documented in man 8 pam_unix. If I'm reading this correctly, the proper file to edit would be /etc/pam.d/login where the line "password sufficient pam_unix.so sha512 rounds=1000000 shadow nullok try_first_pass use_authtok" should be added. Password hash rounds control seems to be almost unused. I got no responses in the CentOS 5 Security forum or on the general CentOS email list. People do not seem to understand how important this can be to password security. According to the oclHashcat (hashcat.net) documentation on the fastest GPU enabled PC they have tested, they get 797 million CPS (cracks per second) against SHA512. If the super fast PC is compared to the single CPU PC with no GPU, using the only algorithm common to all tests (NTLM), there is a speed difference of 1981 times. This suggests roughly 400,000 CPS against SHA512 on the single CPU PC they tested. (Each hashing algorithm interacts differently with the various hardware test configurations, so using one algorithm to estimate how another will perform on a different machine is only a crude estimate. Below, the numbers are discussed like reliable estimates, but until empirical evidence establishes the actual rates in a specific situation, none are reliable.) The Hashcat single CPU machine has an AMD Phenom II X6 1090T clocked at 3.8 GHz. The test times of single CPU PCs without GPUs are relevant because the GPU enabled, oclHashcat, cannot run a simple dictionary word list with no transformations. oclHashcat must have, brute force characters added to either or both ends of the words in a list. To run a list of the 10,000 most common passwords, without transformations, you need to use the single CPU Hashcat or the deprecated GPU oclHashcat-plus. It seems there is no efficient way to make use of a massively parallel architecture using a simple word list. oclHashcat also cannot process the "Rule-based Attack" which corresponds with the transformations found in John the Ripper. Again one must use the single CPU Hashcat or the deprecated oclHashcat-plus. So, oclHashcat is blindingly fast with a GPU on brute force and related attacks but cannot process the most obvious dictionary or do the most productive transformations of a dictionary containing real words and names. The most productive transformation is checking the first character, and only the first character, for upper and lower case, in combination with appending 1, 2, or 3 digits to the end of the word. The third digit would be very low yield compared to the first, but still very high compared to any pure brute force attack. If these issues are indicative of a problem that does not fit well with a massively parallel architecture, and not limitations of the oclHashcat developers, there are significant implications for password security. Simply put, password hash round controls can be used to deny crackers most of the space where modified dictionary attacks get the weak, but not blatantly bad, passwords. If Hashcat is run against the default configuration of SHA512 on my desktop PC, roughly 240,000 CPS seems plausible. Unless there is a fast implementation of SHA512, the use of 1,000,000 hash rounds, which takes about 2 seconds to authenticate on an AMD Phenom II X6 1090T, should slow the the cracking process down to about 0.5 CPS, or more than a five orders of magnitude difference. A simple list of the 10,000 most common passwords might take perhaps 5.5 hours with a million round SHA512, rather than about 5 seconds against the default SHA512. On most systems, the top 10,000 passwords, should get 70% to 95% of the passwords. Five hours isn't very long but it's a lot longer than 5 seconds. Where the slowdown really hurts the cracker is in the subsequent runs of reduced efficiency but still productive dictionaries and transformations. One option might be to use the next next million most common passwords. A PC 4 times as fast as the Hashcat single CPU PC should approximate a current, high end PC, and run about 4 CPS against the million rounds SHA512. The million words takes just under 70 hours; that should crack another few percent. Next might be a small 35,000 word dictionary of common names and and mostly common words. The most productive transformations should be both upper and lower case on the first letter, plus 1 through 3 digits appended to the end. That's 77.7 million test passwords taking just about 225 days. If a PC is 4 times faster than the Hashcat test PC against the standard configurations of SHA512, that is 1.6 million CPS. The million rounds configuration takes 228 days for the first 78.7 million test passwords; the default SHA512 configuration is 49 seconds. One is doable but takes commitment, patience, and resources; the other is trivial. Each successive dictionary plus transformations tends to get larger with a lower positive result rate. Any sane person will stop earlier, with regards to how many dictionaries are used, when they see they are faced with an abnormally high number of hash rounds; it shows up very plainly in the hash, just after the "$6$" as "rounds=1000000". A two second delay for logins or su's may seem like a lot, but we wait longer many times a day for various computer events, none of which get us the added security that a million rounds on a sound hashing algorithm with good salts gets us. A one to two second delay is quite perceptible. If this is not acceptable, then a target time between 0.1 and 0.2 seconds should not be noticeable, but still imposes a massive penalty on the cracker. This is a security freebie. For a fairly minor configuration change, system administrators can role back cracking times 2 or more decades. They only need to determine what is an acceptable delay for authentication on their systems, and how may hash rounds it takes to get in that range. Decent 8 character passwords become almost uncrackable. George Shaffer

1 0

Missing Announcement
by Markus Falb 04 Feb '14

04 Feb '14

Hi, I do see a kernel update to 2.6.18-371.4.1.el5 but I am missing the announcement. -- Kind Regards, Markus

4 4

what is difference between ifconfig and ifup?
by mcclnx mcc 03 Feb '14

03 Feb '14

I and testing command line to up and down ethernet connection. if I perform following, client can not re-connect. ifconfig eth0 down ifconfig eth0 up if I use following, client can re-connect: ifconfig eth0 down ifup eth0 What difference between "ifconfig up" and "ifup"? thanks.

2 1

[solved] filesystem read only after logrotate CentOS 5
by Helmut Drodofsky 03 Feb '14

03 Feb '14

Helo, the solution was now found in dmesg. I/O error for the journal. dmesg was updated, /var/log/messages not. I think because of read only file system. Best regards Helmut Helo, up to 04:02 the root file system was OK. With the logrotate activities there are messages: read only. Last entry in /var/log/messages is the sendmail entry from logrotate. less /etc/mtab gives: /dev/sda1 / ext3 rw 0 0 proc /proc proc rw 0 0 sysfs /sys sysfs rw 0 0 devpts /dev/pts devpts rw,gid=5,mode=620 0 0 tmpfs /dev/shm tmpfs rw 0 0 none /proc/sys/fs/binfmt_misc binfmt_misc rw 0 0 sunrpc /var/lib/nfs/rpc_pipefs rpc_pipefs rw 0 0 What has happend? Is this problem related with https://bugzilla.redhat.com/show_bug.cgi?id=947149 Best regards Helmut -- Viele Grüße Helmut Drodofsky Internet XS Service GmbH Heßbrühlstraße 15 70565 Stuttgart Geschäftsführung Dr.-Ing. Roswitha Hahn-Drodofsky HRB 21091 Stuttgart USt.ID: DE190582774 Tel. 0711 781941 0 Fax: 0711 781941 79 Mail: info(a)internet-xs.de www.internet-xs.de _______________________________________________ CentOS mailing list CentOS(a)centos.org http://lists.centos.org/mailman/listinfo/centos

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss