Discuss

discuss@lists.centos.org

1 participants
34753 discussions

Re: [CentOS] Hot swap CPU
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: Peter Arremann <loony(a)loonybin.org> > Actually that was exactly the point. The email I responded to was > mentioning ancient US-I/II frames as a solution for the hotswap issue. My > point was that for the same cost I can get a 8way E4500/400/4MB or a nice > P4 PC... > From the speed perspective you'll be hard pressed to find an app > that is faster on the sun and the age of the E4500 negates any advantage > it used to have in reliability. The E4500 doesn't even have redundant > power :-) Be careful with your continued assertions. I/O on the P4 (and the PC platform) _sucks_ compared to many of these solutions. PCIe is _not_ the "holy grail" for a platform that has some severe bottleneck issues in its design, let alone when we're talking a single processor versus a partial mesh system with a _real_ "system interconnect." ;-> Reality: Even a 200MHz, non-superscalar microcontroller prototype boards can handle 500MBps+ of storage I/O, but many PC mainboard I/O designs can_not_. ;-> > I was giving the E4500 as a comparison because it costs the same. > Unfortunately we got apps here that outgrow F15K frames - performance > can't ever be good enough. > But even if you get a V440 (from integer processing the currently fastest > cpu Sun has to offer) you're still so much slower when doing compiles. Once again, I will re-iterate, build times are _not_ a good "server benchmark" at all. If they were, then I don't know why _anyone_ would buy Intel -- AMD _roasts_ P4 _over_ 2:1 MHz for MHz. > Anyway, point I was trying to make is that if anyone points a US-II based > frame today they are mistaken about its performance and reliability. I don't think people were asserting "build" time at all, let alone performance in general. But there are some advantages to deploying even older SPARC platforms in some areas. It's obvious your experience has largely been in "build" or "dynamic web app" benchmarks. Please be considerate that it's not the _only_ "performance" consideration out there. ;-> > Just the disks in D1000 trays are so much of a headache that you > wouldn't believe it. And Sun doesn't support booting of EMC on the > smaller frames - so you need some local attached storage... There are options around that in various hardware selections. But yes, Sun does have some stock SAN limitations. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > Nope. On Windows during login users usually selects domain part from > drop-down box (yes, you can type it too if you want). [ Not that this matters, but ... ] First off, that's _only_ for the GINA portion, and not always. Unless you take the time to distribute all domains either at the server or client, you won't always see all domains. Secondly, inside of various apps, credentials are not always passed correctly, which requires the nomenclature. Of course, the application can save the username and other settings in the application itself. E.g., try to login to IIS' FTP server when you have multiple domains. ;-> You'll have to pass the DOMAIN/user nomenclature in many cases. > And usually whatever domain is selected in that drop-down box by > default is the correct one for the owner of the particular PC. [ Again, not that it matters, but ... ] And the same can be said for applications on a UNIX system with a particular user's login, and their configuration files (and mounted home directory -- you are automounting home directories, yes?). I'm kinda scratching my head here. I can setup a user's IMAP credentials in various applications (both Windows and UNIX/Linux) to remember their username for the setup, so that is avoided. I don't see the difference between multiple REALMs and multiple NTDOM/ADSDOMs. If you properly configure the login/apps to remember the user's domain, then it's not an issue. > Anyhow, historically real Unix accounts were used on email servers, > so after switch to virtual accounts requirement was that users don't > notice the change. Higher authority decided that it would be too > complicated for non-technical population to swtich from "username" > to "username@REALM". [ Lastly, also mot that it matters, but ... ] What are you using multiple REALMs for anyway if everyone was under a "real UNIX" account before? NOW WHAT MATTERS ... _Please_ read up on how NsDS works. It's _extremely_ "enterprise class" and much more capable than OpenLDAP, which was more of an "open framework" of different capabilities (not always well integrated). http://www.redhat.com/docs/manuals/dir-server/ag/ssl.htm "Netscape Directory Server Administrators Guide Chapter 11 ... Configuring Kerberos Kerberos v5 must be deployed on your system to utilize the GSS-API mechanism for SASL authentication ... ... Realms A realm is a set of users and the authentication methods for those users to access the realm. A realm resembles a fully-qualified domain name and can be distributed across either a single server or a single domain across multiple machines. A single server instance can also support multiple realms. Realms are used by the server to associate the DN of the client in the following form, which looks like an LDAP URL: uid=<user_name/[server_instance]>,cn=realm,cn=mechanism,cn=auth " Is that more of what you were looking for? How to put the Realm in the uid? -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: [CentOS] Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > As I said, there are multiple domains, so IMAP server can't simply slap > @REALM to the end of user supplied username and do the check directly. Ahhh, a key point I missed. My apologies. > For historical reasons, IMAP server uses flat userspace (while in reality it > is more tree-like). And nope, having users type the @REALM part during > login is not acceptable solution (most of them don't even know what > @REALM should be, nor should they be bothered with such details). Hmmm, most usrs have to do DOMAIN/user for Windows DCs so I don't know how "unacceptable" is is to require "@REALM," but that's just my view. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

Re: Software RAID muck up
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: Dan Pritts <danno(a)internet2.edu> > I just looked at that a few weeks ago - it doesn't seem to have reached > critical mass. Would sure be nice. Oh, it _has_ reached "critical mass" among a lot of embedded and application-specific capabilities. But like most distribution channel issues, you can be sure that AMI, Phoenix and others are fighting it quite hard. Even Intel's so-called "open" initiatives are still in the "tight knit group" of BIOS vendors. And Microsoft would love nothing more than to make it impossible to access system configuration outside of Windows, Windows systems unable to boot be damned. Most hardware vendors are _also_ more than happy to see this, because they can start tying hardware to specific Windows versions. Hence the entire "superstore" hardware/distribution issue that will always plague Linux and partnerships to create Linux drivers. > heck, i'd settle for getting serial-bios capability out of commodity > motherboards. "server" systems (and maybe high-end "workstation" > motherboards) have it but things like the via c3 boxes i have posted > about before generally don't. I'm waiting to see what Apple cooks up. They won't share it, but it will possibly create enough stir to change the industry in general. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Re: [CentOS] Re: Installing Dag's RPMs
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > Which is the smallest problem with Sun'S Java. They don't do "alternatives" > either (you have to set them up manually, if you want to have GCC's Java in > parallel). And Sun's license doesn't allow anybody to repackage it so that it > blends with the rest of the particular distribution (basically, fixing the > problem you had and the alternatives issue). Yeah, that's the #1 issue most everyone has with Java. Sun allows the JRE to be bundled with Solaris and Windows applications, but not Linux. And you have to be the size of Red Hat or SuSE to negotiate otherwise, and that's just for retail distributions. If they SCSL/whatever it into an MPL-like, that should change though. Java seems to be the _only_ thing Sun hasn't GPL'd or at least MPL'd. While I can understand some aspects of their viewpoint, the explicit denial of redistribution on Linux is just entirely inexecusible when they allow it to be bundled with Solaris and Windows applications (let alone the OSes). -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Problem with yum/kdevelop?
by Joshua Weage 30 Jun '05

30 Jun '05

I've produced a custom rpm for kdevelop 3.0.1. However, yum reinstalls the original CentOS rpm when I do 'yum update'. Yum shows the following for kdevelop: >yum list kdevelop -------------------------------------------------------------------------------- kdevelop i386 8:2.1.5-12.1 base Looking in Installed Packages: Name Arch Version Repo -------------------------------------------------------------------------------- kdevelop i386 3.0.1-1 db If I then to a "yum update", it will prompt me to install 2.1.5 over the top of 3.0.1, as it is reporting the version as "8:2.1.5-12.1". The header for kdevelop is named: kdevelop-8-2.1.5-12.1.i386.hdr Can anyone tell me why the header for kdevelop has a leading 8 rather than 0? Thanks, Josh ____________________________________________________ Yahoo! Sports Rekindle the Rivalries. Sign up for Fantasy Football http://football.fantasysports.yahoo.com

3 2

Hot swap CPU
by Peter Arremann 30 Jun '05

30 Jun '05

Sorry to disrupt the thread - my mail reader chewed up half my inbox today... alex(a)milivojevic.org wrote: > E4500 is discontinued for some time now. It is rather old machine, much > older that the above mentioned P4. I doubt that Peter's intention was to > compare speed of Sun's server in general with the speed of > latest-and-greates P4 systems. I hope that he simply forgot to mention > how much older that E4500 is than the P4 box. Actually that was exactly the point. The email I responded to was mentioning ancient US-I/II frames as a solution for the hotswap issue. My point was that for the same cost I can get a 8way E4500/400/4MB or a nice P4 PC... From the speed perspective you'll be hard pressed to find an app that is faster on the sun and the age of the E4500 negates any advantage it used to have in reliability. The E4500 doesn't even have redundant power :-) <snip> > People that buy E4500 nowdays are either buying them for spare parts, or > they simply want redundant box exactly the same as the old box they > already have. Or people that simply need some Sparc hardware around, > but don't want to spend money on current line of Sun's servers and don't > care if the system is slow as long as it does the job (my guess is > Peter's company falls into this category, from what he wrote, otherwise > they would be running their Sparc builds on something more recent) I was giving the E4500 as a comparison because it costs the same. Unfortunately we got apps here that outgrow F15K frames - performance can't ever be good enough. But even if you get a V440 (from integer processing the currently fastest cpu Sun has to offer) you're still so much slower when doing compiles. A build that can be done on a single cpu linux box (3.2Ghz P4) is a fraction of the time of that V440 time... Compiles aren't a great benchmark for a box since its 100% cpu and neglects memory or disk performance but I had the numbers handy for that :-) Anyway, point I was trying to make is that if anyone points a US-II based frame today they are mistaken about its performance and reliability. Just the disks in D1000 trays are so much of a headache that you wouldn't believe it. And Sun doesn't support booting of EMC on the smaller frames - so you need some local attached storage... Peter.

1 0

Re: [CentOS] Directory Server for CentOS 4.1
by Bryan J. Smith <b.j.smith＠ieee.org> 30 Jun '05

30 Jun '05

From: alex(a)milivojevic.org > Hm, sounds interesting alternative to OpenLDAP. Actually, OpenLDAP started as a GPL alternative to NsDS as far as I am concerned. @-p > It says it supports SASL authentication and MD5 password hashes. > Does it also support placing a pointer for SASL where to check the > password into password attribute (instead of placing actual password > in it)? The SASL capability can interface with any GSSAPI solution IIRC. I _know_ that includes a _real_ KDC. > What I'm talking about is putting something like "{SASL}user@REALM" > intopassword attribute. OpenLDAP would than use saslauthd to check > the password(passing it user@REALM and whatever user entered as > password). In my case saslauthd is configured to check passwords > using kerberos5 backend. > Basically, directory server does not store any passwords, passwords > are stored in Kerberos database That's _exactly_ how most enterprise have been running NsDS since the '90s, using Kerberos as the authentication end. > (and I have users spread across several distinctive Kerberos realms > (some Unix based, some Windows AD), to make things even more > interesting). The Florida Institute of Technology created a Windows side service called "acctsync" so a segmented ADS tree could pull/push password and other, basic meta-data changes. This was because more and more ADS-only Windows applications were being implemented, but they still wanted to keep NsDS as their "root" tree (where _all_ users were _always_ created/ removed first). Translation: FIT's AcctSync turned ADS into NsDS' bitch. This was _before_ MS Kerberos was even published, let alone any such interoperability, hence FIT's need and eventual solution. It doesn't use network services and protocols, but is a service that runs on the Windows DCs themselves. The Windows DCs pull/push from/to the NsDS LDAP stores. http://acctsync.sourceforge.net/ [ Side Note: FIT actually didn't use SASL to Kerberos for their password store, but hashes in the directory. But it would have worked for the SASL/Kerberos options too IIRC. ] > (having that functionality is "must-have" for me, before even thinking > about downloading FDS to try it out). Trust me, NsDS has been supporting these details for a _long_ time. Some of it has been with 3rd party software, but others have been BSD, GPL and other projects built around NsDS, even if it wasn't GPL before Red Hat. -- Bryan J. Smith mailto:b.j.smith@ieee.org

2 1

an rpm howto question
by Nielsen, Steve 30 Jun '05

30 Jun '05

I am in a precarious spot.... I run centos 4.0. I upgraded my mod_perl RPM to mod_perl 2.0.1. CGI.pm 3.10 (3.05 comes with centos 4.0) fixes some namespace issues with mod_perl vs mod_perl 2.0.1. I need to upgrade to it to 3.10. Yet that file belongs to the perl rpm that comes with centos. What do people generally do in this type of situation? Do I need to compile a new perl just to upgrade CGI.pm to a newer version? Can I package the new CGI and install it ? If I do CGI.pm will be owned by 2 packages (the one I package and perl). Thoughts , ideas? Steve

3 2

RE: [CentOS] rpm spec file for "fakejava"
by Ash Christopher 30 Jun '05

30 Jun '05

Instead of faking the RPM database into thinking Java is installed, you could try installing Java via rpm. Check it out here: http://www.jpackage.org/rpm.php?id=2663 You basically download the Java binary, manually copy it into /usr/src/redhat/SOURCES and then perform an rpmbuild to make the actual rpm. -----Original Message----- From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On Behalf Of Dan Pritts Sent: Thursday, June 30, 2005 10:00 AM To: Robert Hanson Cc: centos(a)centos.org Subject: [CentOS] rpm spec file for "fakejava" Interestingly, i just posted to the list a similar SPEC file. look at the thread on CGI.pm. I've attached my spec file for "fakejava" as well. It was a lot of trial and error to make it work. None of the documentation I could find was for modern versions of RPM, and IIRC the documentation i did find for older versions was incorrect somehow. I think I had to specify a source package, but i didn't have to actually do anything with it. I'm cc'ing the list on this so it makes it into the archives. On Thu, Jun 30, 2005 at 08:53:06AM -0700, Robert Hanson wrote: > off list greetings! > > would you please share that expertise you just learned with me individually > or with the whole list please? > > that is, if it doesnt take you too long can you detail and share your > creation and how to use it etc that i may learn from it? > > thanks! > > - rh > > -----Original Message----- > From: centos-bounces(a)centos.org [mailto:centos-bounces@centos.org] On Behalf > Of Dan Pritts > Sent: Thursday, June 30, 2005 8:33 AM > To: CentOS mailing list > Subject: Re: [CentOS] Re: Installing Dag's RPMs > > On Tue, Jun 28, 2005 at 03:11:38PM -0700, dan.trainor wrote: > > cryptic nature. I've been doing a LOT of RPM exploration over the past > > few weeks, and found the process of actually creating an RPM to be a > > somewhat cumbersome and at times poorly documented system. I don't want > > Tell it, brother! > > I spent three hours figuring out how to write a spec file to create > an RPM that doesn't do anything other than tell the RPM database > that such and such a capability is installed (some java app didn't > think i have "java" since sun's rpms didn't tell RPM it was there). > > ugh. > > danno > -- > dan pritts - systems administrator - internet2 > 734/352-4953 office 734/834-7224 mobile > _______________________________________________ > CentOS mailing list > CentOS(a)centos.org > http://lists.centos.org/mailman/listinfo/centos > danno -- dan pritts - systems administrator - internet2 734/352-4953 office 734/834-7224 mobile

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