Discuss June 2005

discuss@lists.centos.org

197 participants
362 discussions

CentOS-announce Digest, Vol 4, Issue 11
by centos-announce-request＠centos.org 27 Jun '05

27 Jun '05

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. CentOS-4/alpha 4.1beta is there to play (Pasi Pirhonen) 2. CESA-2005:524 Moderate CentOS 3 i386 freeradius - security update (Tru Huynh) 3. CESA-2005:524 Moderate CentOS 3 x86_64 freeradius - security update (Tru Huynh) ---------------------------------------------------------------------- Message: 1 Date: Sun, 26 Jun 2005 18:32:38 +0300 From: Pasi Pirhonen <upi(a)iki.fi> Subject: [CentOS-announce] CentOS-4/alpha 4.1beta is there to play To: centos-announce(a)centos.org Message-ID: <20050626153238.GM21054(a)core.upi.iki.fi> Content-Type: text/plain; charset="us-ascii" Hi, I've always been kind of on/off with alpha. Remember making some kind of debian/alpha installer back -97ish. Lately (like past 2 years), i've been compiling SRPMS on alpha too from time to time. Most of my alpha hardware was pretty much ancient crap, so i wasn't quite confident pushing anything out to public as i wasn't able to test even if EV6 would be ok. Little over week ago i got a AlphaServer ES45, which was the turning point on this all (i thank you whom gave me this box once again even tho i cannot reveal any names). There is lot to personally thank for AlphaCore project as some of the patches i got directly from that work, would have been nasty for me to spot out. I just don't feel that building FC3 for alpha is enought and will be long term maintainable. That's where CentOS-4/alpha should kick in as the basic codebase should be maintained next 7ish years. There are modified SRPMS beoynd the normal CentOS mods, but it's some 30ish of those now, so it's only really few of them all. AVAILABILITY: http://beta.centos.org/centos/4.1beta/isos/alpha/ - which does have ISO-images and .torrent files for CD/DVD-images. - DVD-image does contain full binaries + source - ISOS labeled 'bin' are binaries only - ISOS labeles 'src' are the sources http://beta.centos.org/centos/4.1beta/os/ - which is unpacked, installable tree. http://beta.centos.org/centos/4.1beta/ - generally as this is the point when the yum config should point for updates etc. BETA RELEASE INFO: It ain't perfect. There are lot to improve still. I just wanted to make this public beta now so there might be some community interest/help for making it really smooth. One thing woth of mentining is that CFLAGS have been '-mtune=ev6' for all the packages, that does obey normal rpmbuild process. I am not sure what the impact is in real life, but IMO it won't make a really slow hardware any _slower_ and might even a little faster for anything useable (no pun intended. 'useable' may vary from person to person :) EXPECTED FINAL RELEASE TIME: I'd expect this to be bit much polished up time of CentOS 4.2 will be reality. At least it's where i am aming for final release. TESTED PLATFORMS: - a quad-1GHz ES45 w/ Radeon 9250 (PCI) - a AlphaStation 255/233 (text mode install) - a AlphaStation 1000 (text mode install) - ES45 was trested with console=ttyS0 too from the DVD KNOWN ISSUES: - The kernel isn't stock same one it's in other CentOS-4 releases - The php was replaced with new one - compat-glibc isn't there yet. Neither the later one or the Compaq release Redhat 7.2 one. I've patched the compat-glibc-2.3.2-95.30axp.src.rpm to build, but it was too late to include it to ISOs as i haven't had much time to test it and there is not real needs for this. - anaconda is putting the 'rhgb quiet' on command line even after text installtion, which might just crash the boot as graphics we're asked for first place. - the DVD isn't working at least on my ES45 with IDE-drive. SCSI is fine. I have to look about mkisofs ordering, because that might just be so that those needed files are 'unreachable' for SRM w/ IDE. - the aboot menu lacks the predefined selection for 'text askmethod' for forced text mode instalaltion from net for example. Forgot that one. - SELinux rulesets aren't quite right for everything, so disabling/making it warn level lets it boot better now on installation. - I've built some of the packages by disabling the checks at buildtime, so there might be 'non-working' software. namely gmp, subversion from memory. INVOLVING: - join the mailing lists at http://lists.centos.org/mailman/listinfo/centos http://lists.centos.org/mailman/listinfo/centos-devel - mail me directly to upi(a)iki.fi - more information from http://www.centos.org/ That's about it. I am sure i've already forgotten much i ment to say on this beta release announcement, but now i do push send and worry things later more. -- Pasi Pirhonen - upi(a)iki.fi - http://iki.fi/upi/

1 0

Multiple system updates
by Peter Arremann 27 Jun '05

27 Jun '05

This is a question for you guys out there that have a bunch of similar configured systems out there... How do you handle your updates? I do not mean the technical level, but from the logistics. No updates? Just run yum by cron and grab the latest of the web and trust the developers that it works? Deploy only certain packages automatically (i.e. omit kernel updates)? run your own yum/apt/up2date/whatever repos? Thanks for your time, Peter.

2 1

RE: [CentOS] OT: question on setting up an email server
by Bruno S. Delbono 27 Jun '05

27 Jun '05

> Don't know if qmailtoaster already has been mentioned. It's really easy to > setup and > I'm really happy with my setup. > > http://www.qmailtoaster.com/ >From postfix-users@ Georgi Guninski have found a remotely-exploitable security hole in qmail. <http://www.guninski.com/where_do_you_want_billg_to_go_today_4.html> D. Bernstein denied the claim, classified it as "portability problem" and refused to pay the prize. <http://cr.yp.to/qmail/guarantee.html> Qmail's ML responded nervously to Guninski's post. Like everytime when anyone dare to say anything negative about qmail... It's quite interesting: "I said that Guninski's dick isn't half as big as he's trying to claim." "Go masturbate somewhere else." "Learn to read, moron." Link - http://tinyurl.com/caooe ----

7 10

strange problem on regconizing /dev/sda and /dev/hda
by Ceg Ryan 27 Jun '05

27 Jun '05

I installed a 4.1 x86_64 with kernel 2.6.9-11.ELsmp (rpm) initially. My box is tyan 5350 and a SATA harddisk The install was successful and the harddisk was detected as /dev/sdaX But strangely, when I first reboot my machine. The harddisk change to /dev/hdaX What is the problem ? Below are some of dmesg output hda: WDC WD1200JD-00HBB0, ATA DISK drive Probing IDE interface ide1... Probing IDE interface ide2... Probing IDE interface ide3... Probing IDE interface ide4... Probing IDE interface ide5... Using cfq io scheduler ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 hda: max request size: 1024KiB hda: 234441648 sectors (120034 MB) w/8192KiB Cache, CHS=16383/255/63 hda: cache flushes supported hda: hda1 hda2 hda3 hda4 < hda5 > ide-floppy driver 0.99.newide usbcore: registered new driver hiddev usbcore: registered new driver usbhid drivers/usb/input/hid-core.c: v2.0:USB HID core driver mice: PS/2 mouse device common for all mice md: md driver 0.90.0 MAX_MD_DEVS=256, MD_SB_DISKS=27 NET: Registered protocol family 2 IP: routing cache hash table of 2048 buckets, 112Kbytes TCP: Hash tables configured (established 524288 bind 37449) Initializing IPsec netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 ACPI: (supports S0 S1 S5) ACPI wakeup devices: PCE0 PCE1 PCIX PCIB USB1 USB2 USBE KBC0 MSE0 Freeing unused kernel memory: 164k freed SCSI subsystem initialized libata version 1.10 loaded. ata_piix version 1.03 ACPI: PCI interrupt 0000:00:1f.2[A] -> GSI 18 (level, low) -> IRQ 193 ata: 0x1f0 IDE port busy PCI: Setting latency timer of device 0000:00:1f.2 to 64 ata1: SATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0x1478 irq 15 ata1: SATA port has no device. scsi0 : ata_piix

2 3

"vsftpd is dead but subsys is locked"
by Draden 26 Jun '05

26 Jun '05

If someone could give advice - I am running Centos 4 and on it I am running among other things vsftpd. Today I noticed the ftp services wasn't running, when I went to restart it it says it starts, but there is no pid for it. when I do a status on it, it gives a message saying "vsftpd is dead but subsys is locked" I have tried removing the lock file and no joy. I even just resorted to a reboot hoping that would clear the issue and to no avail Draden -- "Delivery yesterday, Code today, Think Tomorrow"

2 2

Re: Raidcore SATA support
by Bryan J. Smith <b.j.smith＠ieee.org> 26 Jun '05

26 Jun '05

From: Mark Weaver <mdw1982(a)mdw1982.com> > Hi all, > I was wondering if anyone has tried and succeeded to use this > controller. Its the bc4852 SATA controller. There's supposed to be > support for it, but so far we've not been able to get the driver to load > during the install and thus we've got no "valid drive" on which to load > the OS. Last time I checked, but I could be wrong, Broadcom's RAIDCore solutions are FRAID. They are very, very high-end FRAID designs (PCI-X, 8 channel), with lots of software IP for rebuild options, etc..., but still FRAID. I've never personally tried the cards because they aren't any cheaper than 3Ware solutions. But they claim integration tools with Linux's LVM/MD (I have no idea how these work) and should have at least ATA/SATA channel drivers for just a bunch of disks (JBOD) as with any ATA/SATA controller. Luckily Broadcom's new IC for either PCIe x4 or PCI-X 1.0 is an intelligent, MIPS-based hardware solution for either SATA or new Serial Attached SCSI (SAS). The pricing should be similar with the controller being under $60/1K quantity, but finally bring some serious performance to the table (along with up to 768MB of battery-backed DRAM). -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 4

Getting Mailman Running
by John Hinton 26 Jun '05

26 Jun '05

On a CentOS 4 box, I'm trying to get Mailman running. I found the apache conf file in /etc/httpd/conf.d and set the servername in that. When I try to go there, I get a 500 internal server error.. when I try to start Mailman, I get Starting mailman: Site list is missing: mailman I've never run Mailman before.. looked in the /etc/mailman/sitelist.cfg.. don't see anything in there that needs to be set. man mailman shows no entries..... I installed it via rpm at server install time. I am running sendmail. python is installed... I can't seem to find much to help. Thanks, John Hinton

2 3

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 26 Jun '05

26 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Then the first AnandTech benchmark article > (http://www.anandtech.com/IT/showdoc.aspx?i=2447) is exactly what you want to > look at. Huge amount of memory (when compared to the size of the database > running on the system) on a 64bit linux kernel... > We're doing the same for one of our apps called IPM. Its a PHP app running > against a quad opteron with 16GB ram. Heavy on network IO (during business > hours its rare that we don't saturate the main 100mbit link) but little disk > activity. DB size is about 2.5GB and we end up with a couple of gig for disk > buffers. CentOS4 of course... anything specific you're looking for? I think I know where you and I are differing. When you talk about "heavy [network] IO," you refer to SQL-based applications over a primary 100mbit link. In reality, the MCH bottleneck isn't much of an issue here. When I talk about "heavy [network] IO," I'm typically referring to less intelligent applications (e.g., NFS or other "raw block" transfer) over one or even multiple GbE, possibly FC-AL links (possibly direct IP, link agregated IP, maybe 1 out-of-band channel, or possibly to a Storage Area Network, SAN). Although I have built financial transaction systems that have required GbE as well as engineering. I guess this is where my terminology really differs. A lot of people are using Linux for Internet services. I've typically been using Linux for high-performance LAN systems -- both "raw block" as well as intelligent applications. My Internet connection is not my bottleneck. BTW, despite popular thought, this can be done quite inexpensively when needed. It really all depends. But in these applications, definitely _not_ going to see Opteron doing much for you over Xeon. Let alone not when running Linux or Windows (Solaris might be another story though). -- Bryan P.S. Just a follow-up, _never_ assume you're the only EE in a thread. [ Let alone don't assume I haven't designed memory controllers as part of my job, beyond just my option in computer architecture. That's why I had to "give up" in the other thread, because everytime I try to explain something, you are going to a very simplified path and I have to stop and explain it (e.g., the fact that IA-32/x86 _can_ address beyond 4GiB). ] -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 2

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 25 Jun '05

25 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Actually apps like the one I was referring to showed about 50% > single thread performance gain when going from a 2.4GHZ Xeon > to a 2.2GHz Opteron. That's not a good comparison because the ALU-Control of the Athlon is about 50% faster MHz for MHz than P4-Xeon. So that could easily be a computational benefit and not an interconnect one. > Never assume you've done more more than others either :-) I didn't. > I've done the more difficult job with finding all the applicable documents Dude, you did _not_ send me any documentation I have not already seen. I have been using developer.intel.com years in my semiconductor design career, as well as more of an IT-level system designer. The problem here is that you can't seem to understand that a trace does _not_ indicate how something actually works in the memory logic. E.g., the existence of trace does not tell you if a normalized address that results in a PAE36 (>4GiB) address is going to either: A) Directly drive that trace and fetch for the process to use B) Be intercepted by the paging logic, referenced in a page table, then _that_ logic actually fetches the memory, which is then mapped into <4GiB for the process to use It's not just the simple trace, and it's not just the simple, programmer-level logic. If Intel PAE36 processors didn't have address lines above bit 31, they couldn't address above 4GiB at all! But just because they have those traces doesn't mean they can directly use them. First you looked at it from the "programmer" level, then you looked at it from the "board technician" level. Now I'm tell you _get_in_the_chip_! > while you just put out hearsay and "doesn't work like that" statements > without really backing it up. And yes, IA-32 _can_ address more than > 4GB - called PAE. Exactly! What I'm telling you is that _all_ Athlon "32-bit" processors can by-pass PAE36, and significantly _increase_ performance at the page table level. But it requres the platform be configured in a way that is _incompatible_ with all OSes _except_ a hack for Linux. This is rare, but it has been done in a few mainboards. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] [OT] Memory Models and Multi/Virtual-Cores -- WAS: 4.0 -> 4.1 update failing
by Bryan J. Smith <b.j.smith＠ieee.org> 25 Jun '05

25 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Then enlighten me - if I have 40 address bits - transmit only the higher 37 > since I don't need the lower end. Timing schemas show only one Input hold > time per address transfer for all available pins - how can that be a 32bit > bus? (ftp://download.intel.com/design/Xeon/datashts/30675401.pdf) Once again, stop assuming a trace and its specifications for board layout means that memory is directly addressable over those pins. We could go on that all night and for days, and I can give you countless examples of embedded, PC and other memory controllers, memory technology, etc... where paging and other "swap" is required. Heck, as an EE, I would ass-u-me you would have been exposed to memory controller design. It is a complex mess whereby each new change in addressing exponentially increases the transistor count. > And, if timing diagrams, pinouts and so on lie about the size of the bus, > ... cut derrogatory non-sense ... *STOP* This is why I can't even begin. I _never_ said that Intel didn't offer 64GiB (36-bit) memory addressing. The traces _must_ exist so Intel can on [A]GTL+ platforms, but it does not mean that there is not some "paging" going on at the memory _logic_. I just said it cannot address it linearly -- directly by 36-bit -- in the GTL design. It all goes back to Intel's belief that IA-64/Itanium would have taken over the i686/GTL world by now when it decide not to build a new architecture for IA-32 back in the '90s. A belief that Intel has not been paying the price for, and quickly retrofiting everything it can ASAP. AMD decided to switch to EV6 instead as its foundation for _all_ current processors back in 1996+, and that includes tunneling EV6 over HyperTransport in Athlon64/HyperTransport. This has to do with the fact that the Athlon core is a true 40-bit addressing processor, and not 32-bit with PAE36 to page in the "overhang" from a segment+offset that is normalized above 4GB. Athlon just _emulates_ PAE36 for compatibility. If you hit "/proc/cpuinfo" on _any_ Athlon, it will show that the PAE36 flag is supported. PAE36 support has _always_ been in _every_ Athlon because the core design is 40-bit EV6. AMD took the time, effort and transistors to emulate PAE36 at the control, and put in the logic in its TLB and memory controller. If they didn't, then AMD wouldn't be able to run any PAE36 OSes or applications. And even if you don't have more than 4GB of RAM, there is still the memory organization issues. E.g., Red Hat currently ships i386/i686 kernels with the 4G+4G model which hurts performance over the 1G+3G model. Why does it hurt performance? Because it either relies on the PAE36 paging logic, or a software emulation of it (if the processor does not support PAE36). With the BIOS hack and kernel, this allows Athlon MP to linearlly address directly above 4GB. Intel is _finally_ just coming out with its first, true 40-bit physical interconnect that breaks the limitations of GTL. People should be wary to _not_ go with the majority of Intel's existing platforms because of this, even those with EM64T. Only these newer platforms. > And if its not, then your whole speach about the pae36 > differences between a gtl+ or ev6 connected device is > wrong, which then in turn makes the only real difference > the iommu the newer athlon cores provide (so dma can go > above the first 4GB rather than having to be bounced)... > This is also supported by the intel, amd and redhat docs > (see links posted above and in previous mails), the post > Feizhou made in this thread convering the LKML references about > using the apggart and even microsoft > (http://www.microsoft.com/whdc/system/platform/server/PAE/pae_os.mspx) I know, I also posted it, and there are even _more_ comments in the LKML. There are comments on how AMD has extra GARTs in the Athlon (yes, even the so-called "32-bit" Athlon) to handle _all_ I/O, not just AGP (long story). But I'm not talking just about that. I'm talking about the serious limitations with GTL itself -- even on Socket-640 and Xeon EM64T. It's only the latest > *shrugs* Intel, AMD and any other spec sheet you can find down > to VIA chipset docs agrees with that... But I guess I'm still > wrong though? Dude, you are using _board_level_ spec sheets. I'm talking about the _internal_ design of the CPU/interconnect and how it handles the addressing between the systems software and interconnect. You get that from _neither_ of the "board level" spec sheets _nor_ the "programmer" guides. You have to find more eccentric docs, many times, they are not on-line. Intel is not going to boast how even their AGTL+ chipsets with first-gen EM64T can't directly address above 4GiB because of legacy design limitations in the platform. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
37
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss June 2005