Discuss July 2013

discuss@lists.centos.org

167 participants
150 discussions

DL380g8 - smart array B320i - CentOS 6.4
by Sergio Alex 02 Jul '13

02 Jul '13

Gostaria de instalar o Centos 6.4 em um dl380e g8 com uma smart array b320i, na instalação não possui drives por isso aparece que não há discos disponíveis, baixei os drives para red hat .dd do site da HP, como poderia carregar esses drives durante a instalação? gravei eles em um pen drive. Obrigado. -- Sergio.Alex

12 18

CentOS-announce Digest, Vol 101, Issue 1
by centos-announce-request＠centos.org 02 Jul '13

02 Jul '13

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. CEBA-2013:1004 CentOS 6 java-1.7.0-openjdk Update (Johnny Hughes) 2. CEBA-2013:0739 CentOS 6 bind-dyndb-ldap Update (Johnny Hughes) 3. CEEA-2013:1007 CentOS 6 resource-agents Update (Johnny Hughes) ---------------------------------------------------------------------- Message: 1 Date: Mon, 1 Jul 2013 17:53:16 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2013:1004 CentOS 6 java-1.7.0-openjdk Update To: centos-announce(a)centos.org Message-ID: <20130701175316.GA46104(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2013:1004 Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-1004.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 494da8188580aecf2741a2990b9b25af329f3cec0d8993ce992fe93ba64f0ebe java-1.7.0-openjdk-1.7.0.25-2.3.10.4.el6_4.i686.rpm dd1213274089ae43c7b4beb9cf4cb1b9ec07acf47a4e3fbcfeb99f47628b462a java-1.7.0-openjdk-demo-1.7.0.25-2.3.10.4.el6_4.i686.rpm 0e0419262b08e8c332e4136aa0c0458454ed69dbd3075a95b6b8b1c2fd3f1b22 java-1.7.0-openjdk-devel-1.7.0.25-2.3.10.4.el6_4.i686.rpm c86a1c937047a8c69f5c7d359fb4fa848be7c3bb8d351b387fded68329e0320d java-1.7.0-openjdk-javadoc-1.7.0.25-2.3.10.4.el6_4.noarch.rpm e9b1e541d5bd59889edde02000ee39f775e2fc11e09495733cb2d0745c73ce30 java-1.7.0-openjdk-src-1.7.0.25-2.3.10.4.el6_4.i686.rpm x86_64: fd81023676da2b1a0cfbe120f9bf85a071b01402d7951a3e4bc89b32893df552 java-1.7.0-openjdk-1.7.0.25-2.3.10.4.el6_4.x86_64.rpm 40e9440ea75d178efdb7556db4c185bbf8c7003df5caf730eda16a228b5e0e06 java-1.7.0-openjdk-demo-1.7.0.25-2.3.10.4.el6_4.x86_64.rpm 2107911d4991ba9d8453f956e2f815d54bcd10b16512092683f99c4205d45d8c java-1.7.0-openjdk-devel-1.7.0.25-2.3.10.4.el6_4.x86_64.rpm c86a1c937047a8c69f5c7d359fb4fa848be7c3bb8d351b387fded68329e0320d java-1.7.0-openjdk-javadoc-1.7.0.25-2.3.10.4.el6_4.noarch.rpm 28979f54d44e0abd09ac72e8c54bf9b82f25ee267b1cfccec71aa5f881cdf575 java-1.7.0-openjdk-src-1.7.0.25-2.3.10.4.el6_4.x86_64.rpm Source: a054f1009f76109035be1178e3a8e0cf297b5840f99a4671b5d2e26b369c7e2e java-1.7.0-openjdk-1.7.0.25-2.3.10.4.el6_4.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 2 Date: Mon, 1 Jul 2013 17:54:10 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEBA-2013:0739 CentOS 6 bind-dyndb-ldap Update To: centos-announce(a)centos.org Message-ID: <20130701175410.GA46359(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Bugfix Advisory 2013:0739 Upstream details at : https://rhn.redhat.com/errata/RHBA-2013-0739.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: d69403f7649804d2fcf9106672a45f98f0e46fb461447ef643d4fa0807609177 bind-dyndb-ldap-2.3-2.el6_4.1.i686.rpm x86_64: 7973907a2ce55383fa09a21e4e6097bbbb0b6feb63e2de8870b0c8f6260aad67 bind-dyndb-ldap-2.3-2.el6_4.1.x86_64.rpm Source: 0e05a97d5ae2a6d59b000fb0770502f660a081df380808595cd97db7a7ca8bb4 bind-dyndb-ldap-2.3-2.el6_4.1.src.rpm -- Johnny Hughes CentOS Project { http://www.centos.org/ } irc: hughesjr, #centos(a)irc.freenode.net ------------------------------ Message: 3 Date: Mon, 1 Jul 2013 17:54:42 +0000 From: Johnny Hughes <johnny(a)centos.org> Subject: [CentOS-announce] CEEA-2013:1007 CentOS 6 resource-agents Update To: centos-announce(a)centos.org Message-ID: <20130701175442.GA46583(a)n04.lon1.karan.org> Content-Type: text/plain; charset=us-ascii CentOS Errata and Enhancement Advisory 2013:1007 Upstream details at : https://rhn.redhat.com/errata/RHEA-2013-1007.html The following updated files have been uploaded and are currently syncing to the mirrors: ( sha256sum Filename ) i386: 081617fb7ccd5da896876579fbf350c34fbe09d86d5ba10979a0dc90e9bbbc89 resource-agents-3.9.2-21.el6_4.3.i686.rpm x86_64: 142f54f22e8a83f450cab39b923cf8540c6de09c2daeec59f85b06fda7b4ecfd resource-agents-3.9.2-21.el6_4.3.x86_64.rpm Source: 4c26ef88b130f4423acd6871fb923712eca206c736ac2e4b0fec49341614b508 resource-agents-3.9.2-21.el6_4.3.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 101, Issue 1 ***********************************************

1 0

Re: [CentOS] Yum hangs while doing anything (FIXED)
by ken 01 Jul '13

01 Jul '13

On 07/01/2013 05:52 PM Eero Volotinen wrote: > is this fixing the issue: > > http://fedoranews.org/alex/tutorial/rpm/16.shtml I couldn't read any web pages because I shut down firefox hours ago (thinking I was upgrading it) and then it (the older version) wouldn't start again. But then I just solved the yum problem, upgraded several apps (including firefox) and the new firefox is working now. All I did was put the original /var/lib/rpm/Packages file back where it was. (If you read from a post from earlier today, I mv'd off this file and then ran rpm --rebuild to recreate it. This fixed the problem with yum hanging, but then I was getting crazy error messages from yum and from rpm.) Something told me to put the original Packages file back where it was, I did, and now yum works again. And the just-upgraded firefox works too. Thanks to you and everyone else who responded. I have to say, I still don't know what caused the problem in the first place. But sometimes things just have to be a mystery.

1 0

Dovecot SLOW with sssd in centos 6
by FABIO FERRARI 01 Jul '13

01 Jul '13

Hello, I have a big performance problem with a mail server using dovecot and authenticating users via ldap. The architecture of the machine is a local ldap and mysql server, they are used by dovecot for authenticating the mail users. If i use pam_sss the mail server has about 1/8 - 1/10 the performances it has if i use the pam_ldap. Even doing a 'time ls -l' on the mail tree (there are about 3000 ldap users in that directory) it is very very slow, the first time I try to do it after a reboot, it takes about 6 minutes with sssd, and about 8 seconds with ldap. Since I know sssd is recommended, anyone knows that there is anything in configuration I can try to increase the speed, avoiding me to use the old pam_ldap module? thanks in advance, Fabio Ferrari

3 2

Yum hangs while doing update
by ken 01 Jul '13

01 Jul '13

About thirty minutes ago I started an update. Everything downloaded fine. But when it came to "Running Transaction", it hung: .... Running rpm_check_debug Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Updating : xulrunner 1/18 And there it sits still. There's plenty of disk space. The load on the CPU is under 1.0. There is some disk activity, but no way so much as to cause anything to hang and no major writing related to yum. Disk reads are just about null, except just now when I grep'ed for something to make sure that the disk could be read. I'm not using even half of the available RAM. Anyone else run into this problem?

3 10

Re: [CentOS] DL380g8 - smart array B320i - CentOS 6.4
by Nathan Duehr 01 Jul '13

01 Jul '13

On Jul 1, 2013, at 12:43 PM, Reindl Harald <h.reindl(a)thelounge.net> wrote: > > > Am 01.07.2013 20:30, schrieb Nathan Duehr: >> The significant problem we ran into was someone at an upstream vendor orders HP stuff via >> individual part numbers in a specific configuration for us, so we get a server, some disks, >> whatever... and assemble them on-site. They didn't know (bad vendor, no donut) about the >> change or spaced it... and didn't send licenses... so you're sitting there with disks in a >> new server, all ready to load the OS as usual... and the OS can't find any disks > > *you* are resposible to hire a *qualified* and *certified* HP partner and not the > cheapest idiot company you are able to find I'd love to tell you who it is, but I'm not at liberty to say. Suffice it to say, everyone on this list knows their name, and they're not exactly a small VAR. Your assumptions are unfounded. Like at most companies, the purchasing folks are as far removed from the actual server operations/build folks that there's a complete disconnect anyway... I could talk to the wall as well as I could specify a vendor. They're pizza boxes. > our HP partner does *any* communication with HP for us as well as watching > that all neded licenses are re-newed before they are running out > > that is why they are certified gold partner and if your's is and does > not work like one it is *up to you* to intervene at HP so your vendor > is losing his gold-partner status They are, and I disagree. HP plays games with vendors and customers, they just deserve to lose them. I have better things to do with my time than tattle-tale on a VAR who's not keeping up on the metric ton of horsepucky coming from HP on what aren't really even high-end servers. Hey, if they want to play hardware licensing games on a giant blade server, okay... no biggie. These are pizza boxes that are literally less than $1000/ea in quantity. Over-engineering them to garner an extra couple hundred bucks to turn on hard disks, is a game... a game by a company not interested or not paying attention to what customers actually use these for... commodity hardware built by a large brand name with the ability to show up the SAME DAY with replacement parts. Otherwise, we'd all just buy the stuff at MicroCenter and let stuff fall out of the cluster as it croaked... the DL360/DL380 series, ain't high-end stuff by a large stretch. > if he does not have you are the fool responsible to hire the wrong one > > hint: no they are not expensive if you have a serious business and > work with the principle "live and let live", ours and his techs > after a few years became *real* friends with a lot of specific > knowledge and if you give them the feeling you would like to > have all for no money it's your fault and you are not a serious > business We get along fine with our VAR, and they've changed how they order those machines now... but HP's silly hardware licensing games are HP's self-created problem, which trickles down to the VARs. That can't be blamed on the VAR. They have hundreds of other vendor's products to keep up with, too. These are the types of cheap servers that the admin has always just TURNED ON THE SERVER AND USED IT. It's a pizza box. It isn't a mid-range HP-UX machine. It definitely isn't a Sun box. The rest of your snotty response and assumptions about the business, have been summarily ignored. Mostly because... a) Hey, it's a sysadmin job and the company is what it is. I've now been through something like 15 companies in my fairly long career (if you want to call it that), since before any company on the planet was using Linux... and some are good, some are bad. It has nothing to do with my opinion of a dumb feature added to cheap pizza box servers. b) Attacking people by claiming their company is somehow bad on a public mailing list is a great way to have your resume' find the round file immediately as soon as anyone recognizes your name on it from the tech lists. Sheesh. c) You're boring me to death. Feel free to say you like the new HP licensing features of their commodity cheap hardware, or you don't. I don't care what you think of any particular company practice here, or our choice of VAR. I *suspect* the person who posted just got the same surprise we did the first time it happened. Here's the kind of stuff people do with pizza boxes... 1. Open box, throw away (oh, I forgot... need to be PC... "recycle") cardboard. 2. Install drives and check nothing got unseated in shipping. 3. Boot and install OS from server or media with automated scripts/etc. 4. Shove in rack at datacenter and let it soak for a couple of days for infant mortality. 5. Send traffic to it and make money with it. HP added: 2a. Go find paperwork from purchasing department or stuffed in one of the many boxes with a pile of new servers to find some stupid license key and type it into BIOS. It's a complete waste of time for such low-end hardware and how most people use it. You ... may enjoy the additional silly step designed to annoy and garner a couple hundred more bucks from you, at your pleasure. The rest of your misguided opinions, as I said, will be summarily ignored. My initial response to the thread was curt and to the point and covered why HP servers now do this, succinctly. And IMHO, accurately. I wish you good tidings, and may you always be the smartest person with the "Best l33t GOLD level VAR EVAR !!1!" LOL... (just a note: I remember when there were no such things as "service levels"... you bought a server, the company would send you caviar and roses and wipe your butt just because you called, because servers were EXPENSIVE... the world got rid of/over that, a LONG time ago... just repeat after me... commodity hardware... commodity hardware... commodity hardware... I'm not saying I LIKE it, but hey... virtual farms and what-not... no one needs a pizza box acting all uppity like it's important in the grand scheme of the data center these days... servers that need things typed into the BIOS to find their hard drives... are dumb. Period.) Nate

5 4

Re: [CentOS] Yum hangs while doing update
by ken 01 Jul '13

01 Jul '13

On 07/01/2013 01:21 PM Reindl Harald wrote: > Am 01.07.2013 19:16, schrieb ken: >> About thirty minutes ago I started an update. Everything downloaded >> fine. But when it came to "Running Transaction", it hung: >> >> Running rpm_check_debug >> Running Transaction Test >> Finished Transaction Test >> Transaction Test Succeeded >> Running Transaction >> Updating : xulrunner >> 1/18 >> >> And there it sits still. >> >> There's plenty of disk space. The load on the CPU is under 1.0. There >> is some disk activity, but no way so much as to cause anything to hang >> and no major writing related to yum. Disk reads are just about null, >> except just now when I grep'ed for something to make sure that the disk >> could be read. I'm not using even half of the available RAM > > what about look in dmesg and/or /var/log/messages? > No. Nothing relevant there.

4 10

Re: [CentOS] Yum errors
by me＠tdiehl.org 01 Jul '13

01 Jul '13

On Mon, 1 Jul 2013, Reindl Harald wrote: > > > Am 01.07.2013 15:36, schrieb me(a)tdiehl.org: >> I have a c6.4 machine that recently had some file system corruption. fsck was able >> repair the file system but I am getting the following error when I try to >> do yum update: >> >> [Errno 21] Is a directory: '/var/lib/yum/yumdb/e/2f883c08e3b596b66fcc19c6b4d73b11c9aaa43e-e2fsprogs-1.41.12-14.el6_4.2-x86_64/checksum_type' >> >> In searching Google, some suggested renaming the yumdb but that just results >> in a traceback when I run yum > > you can do *without any issue* > > rm -rf /var/lib/yum/yumdb/* > rm -rf /var/lib/yum/history/* > > and after *twice* "yum history new" there are no longer tracebacks > been there, done that on a *lot* of machines multiple times to > get rid of this tons of old metadata with no benefit Ok, I am still getting a traceback, obviously, the first traceback is expected but the last one os not. Below is what I did: (router pts4) # cd /var/lib/yum/ (router pts4) # rm -r history/ yumdb/ (router pts4) # ll total 12 drwxr-xr-x. 3 root root 4096 May 6 11:31 repos drwxr-xr-x. 3 root root 4096 Jun 29 14:14 rpmdb-indexes -rw-r--r--. 1 root root 36 May 6 11:31 uuid (router pts4) # yum history new Loaded plugins: downloadonly, fastestmirror, security Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 285, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 136, in main result, resultmsgs = base.doCommands() File "/usr/share/yum-cli/cli.py", line 438, in doCommands return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds) File "/usr/share/yum-cli/yumcommands.py", line 1503, in doCommand ret = self._hcmd_new(base, extcmds) File "/usr/share/yum-cli/yumcommands.py", line 1423, in _hcmd_new base.history._create_db_file() File "/usr/lib/python2.6/site-packages/yum/history.py", line 1645, in _create_db_file cur.execute(op) sqlite3.OperationalError: table trans_beg already exists (router pts4) # yum history new Loaded plugins: downloadonly, fastestmirror, security history new (router pts4) # yum update Loaded plugins: downloadonly, fastestmirror, security Loading mirror speeds from cached hostfile * elrepo: elrepo.org Setting up Update Process Traceback (most recent call last): File "/usr/bin/yum", line 29, in <module> yummain.user_main(sys.argv[1:], exit_code=True) File "/usr/share/yum-cli/yummain.py", line 285, in user_main errcode = main(args) File "/usr/share/yum-cli/yummain.py", line 136, in main result, resultmsgs = base.doCommands() File "/usr/share/yum-cli/cli.py", line 438, in doCommands return self.yum_cli_commands[self.basecmd].doCommand(self, self.basecmd, self.extcmds) File "/usr/share/yum-cli/yumcommands.py", line 232, in doCommand return base.updatePkgs(extcmds, update_to=(basecmd == 'update-to')) File "/usr/share/yum-cli/cli.py", line 725, in updatePkgs self.update() File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 3735, in update updates = self.up.getUpdatesTuples() File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 906, in <lambda> up = property(fget=lambda self: self._getUpdates(), File "/usr/lib/python2.6/site-packages/yum/__init__.py", line 726, in _getUpdates self._up = rpmUtils.updates.Updates(self.rpmdb.simplePkgList(), self.pkgSack.simplePkgList()) File "/usr/lib/python2.6/site-packages/yum/rpmsack.py", line 502, in simplePkgList return self.pkglist File "/usr/lib/python2.6/site-packages/yum/rpmsack.py", line 232, in _get_pkglist csumpkgtups = self.preloadPackageChecksums(load_packages=False) File "/usr/lib/python2.6/site-packages/yum/rpmsack.py", line 979, in preloadPackageChecksums rpmdbv = self.simpleVersion(main_only=True)[0] File "/usr/lib/python2.6/site-packages/yum/rpmsack.py", line 1163, in simpleVersion self._put_cached_simpleVersion_main(main) File "/usr/lib/python2.6/site-packages/yum/rpmsack.py", line 1112, in _put_cached_simpleVersion_main os.rename(rpmdbvfname + ".tmp", rpmdbvfname) OSError: [Errno 21] Is a directory (router pts4) # As you can see, I am still getting the traceback. I also ran the following to be sure I was not missing something else: (router pts4) # rpm -qf /var/lib/yum yum-3.2.29-40.el6.centos.noarch (router pts4) # rpm -V yum (router pts4) # Any ideas what I am missing? Regards, -- Tom me(a)tdiehl.org Spamtrap address me123(a)tdiehl.org

3 3

Re: [CentOS] Yum errors
by me＠tdiehl.org 01 Jul '13

01 Jul '13

On Mon, 1 Jul 2013, Reindl Harald wrote: > > > Am 01.07.2013 15:36, schrieb me(a)tdiehl.org: >> I have a machine that recently had some file system corruption. fsck was able >> repair the file system but I am getting the following error when I try to >> do yum update: >> >> [Errno 21] Is a directory: '/var/lib/yum/yumdb/e/2f883c08e3b596b66fcc19c6b4d73b11c9aaa43e-e2fsprogs-1.41.12-14.el6_4.2-x86_64/checksum_type' >> >> In searching Google, some suggested renaming the yumdb but that just results >> in a traceback when I run yum > > you can do *without any issue* > > rm -rf /var/lib/yum/yumdb/* > rm -rf /var/lib/yum/history/* > > and after *twice* "yum history new" there are no longer tracebacks > been there, done that on a *lot* of machines mutiple times to > get rid of this tons of old metadata with no benefit > > After doing a little more poking around, I moved /var/lib/yum/rpmdb-indexes out of the way and the issue seems to be solved. Yum seems to have recreated that directory and appears happy now. Does anyone know of a downside to doing this? Regards, -- Tom me(a)tdiehl.org Spamtrap address me123(a)tdiehl.org

1 0

Yum errors
by me＠tdiehl.org 01 Jul '13

01 Jul '13

Hi, I have a machine that recently had some file system corruption. fsck was able repair the file system but I am getting the following error when I try to do yum update: [Errno 21] Is a directory: '/var/lib/yum/yumdb/e/2f883c08e3b596b66fcc19c6b4d73b11c9aaa43e-e2fsprogs-1.41.12-14.el6_4.2-x86_64/checksum_type' In searching Google, some suggested renaming the yumdb but that just results in a traceback when I run yum. There are some files in lost+found but I am not sure what the above file should look like and inode numbers are not useful to me. Anyone have an idea how to fix this without reloading the machine? Regards, -- Tom me(a)tdiehl.org Spamtrap address me123(a)tdiehl.org

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss July 2013