Discuss

discuss@lists.centos.org

5 participants
34752 discussions

RE: [CentOS] CentOS on Compaq Proliant Rackmount Servers
by Mark A. Lewis 18 Jul '05

18 Jul '05

> Depending on age of the 1850s and it seems all the 1600s have > an issue when Anaconda is trying to detect USB. Do a no usb > install on those. > Also, on the 1850, if you're using a raid card, you may need > to disable the onboard raid as it can be touchy. Otherwise, I > have 3000Rs, 1850Rs, DL360Rs (which i won't buy again as > these have been the most unreliable) and DL380s, all happily > chugging along on ver 3 and ver 4 installs. I did hit some > snags with LVM conflicts. I think the proprietary scsi > conflicted, but setting up with disk druid has always been reliable. > > John Hinton Let me guess, power supply fan failures on the 360's? If it helps, the newer ones have come a long way. On topic, I have CentOS on: DL360G1 DL380G1 and G2 DL580G1 and G2 PL8000 PL8500 No issues on any of them that I can recall. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.

7 10

RE: [CentOS] CentOS on Compaq Proliant Rackmount Servers
by Bryan J. Smith <b.j.smith＠ieee.org> 18 Jul '05

18 Jul '05

From: Robert Hanson <roberth(a)abbacomm.net> > Is it currently worth getting used dual PIII 1850R's or should I start with > used dual PIII DL380's and like 1Ghz minimum processor speed? Depends, I'll have to investigate the width of the interconnect of a ProLiant 1850 v. ProLiant DL380. This is typically dependent on the chipset. Anything i440 will _suck_. Ideally you want a ServerWorks IIIHE, although a IIILE is at least better than an i440 (but an IIIHE has far better FSB/memory width). > I couldn't find used 1850R's on eBay with more than 600Mhz. That matters little. What matters is the chipset and interconnect. Hmmm ... according to this page (2nd hand, not always ideal): http://www.bnv-bamberg.de/home/ba3294/smp/rbuild/ The ProLiant 1850 is a i440GX (_avoid_, along with i440BX). You're going to be stuck in I/O hell. The ProLiant DL380 is a ServerSet IIILE, not ideal, but better. You at least get 4-8x the I/O of a i440BX/GX. Getting _exact_ model numbers helps. I've seen a few ProLiants mentioned with ServerSet IIIHE chipsets. But I assume those aren't quickly sold. -- Bryan J. Smith mailto:b.j.smith@ieee.org

1 0

Having problems compiling program
by Edward Croft 18 Jul '05

18 Jul '05

I get the errors: zip4_lnx.a(generic.o)(.text+0xb16): more undefined references to `__ctype_b' follow zip4_lnx.a(libdl.so): undefined reference to `_dl_close(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_catch_error(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_addr(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol_skip(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_versioned_symbol(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_symbol(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_loaded(a)GLIBC_2.1' zip4_lnx.a(libdl.so): undefined reference to `_dl_open(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_signal_error(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_global_scope(a)GLIBC_2.0' zip4_lnx.a(libdl.so): undefined reference to `_dl_lookup_symbol_skip(a)GLIBC_2.0' I have the compatibility libraries installed. I have tried using gcc296, gcc, and gcc4 and still get the message. The library,libdl.so.2 is in /lib with a symlink to /usr/lib/libdl.so Using CentOS 4.0. -- If the sane say the insane are insane, What if the sane are insane? Would that make the insane sane? Explains a lot in Washington! --E. Croft

1 0

Netowrk addresses contactor
by Chris Mason (Lists) 18 Jul '05

18 Jul '05

Does anyone know how to control electrical load remotely using Linux? I'm thjinking a network addressable contactor (200 Amp) but I have not been able to source one. -- Chris Mason NetConcepts (264) 497-5670 Fax: (264) 497-8463 Int: (305) 704-7249 Fax: (815)301-9759 Cell: 264-235-5670 Yahoo IM: netconcepts_anguilla(a)yahoo.com

1 0

Re: Fix passwd/shadow/group files? -- Samba 3.0 v. ADS v. CIFS
by Bryan J. Smith 18 Jul '05

18 Jul '05

From: Feizhou > You assume too much and you are not clear enough in what > you post. You didn't even know what a KDC was, so my assumptions were pretty easy to make. You keep saying "Samba, Samba, Samba" over and over like Samba does it all. It does _not_. > Geez....I've been trying to get whether you are saying there was a way > to do the whole ADS DC thing without a MS-Kerberos in the mix. And I've been trying to tell you that: 1) MS Kerberos extensions are now part of UNIX/Linux Kerberos 5 implementations 2) Hence why Samba 3.0 does _not_ provide this, it merely uses it. So _yes_, you _can_ bypass the need for a native Windows ADS DC on your network! But _no_, Samba 3.0 does not provide functionality for sync'ing Samba DC to MS ADS DC. It's an "all Samba" or "all MS DC" choice. > How do you get centralized user account management without > MS Kerberos? Again, MS Kerberos are just extensions to Kerberos, ones supported in new, open source Kerberos 5 servers. If they hadn't, then Samba 3.0 would not be able to act as either a member server in a MS ADS network, or emultate a MS Kerberos KDC without one. This has *0* to do with Samba. There are thousands upon thousands of enterprises running with Novell eDirectory, NsDS, Sun One, etc.. using their own management suite for Windows clients. In many cases, a few are vastly more experienced, featured and superior IMHO. I think what you're looking for is an experience where all the interfaces and schema are emulated to you can run any Microsoft management tools, tools written explicitly for undocumented MS schema and interfaces. You're looking at the problem from an impossible solution standpoint. That's the problem.

2 4

Re: Fix passwd/shadow/group files? -- network architecture is always piecemeal
by Bryan J. Smith 18 Jul '05

18 Jul '05

From: Dag Wieers > Bryan, and you're still belittling people in discussions and get into long > arguments as a result. Pretty please stop doing that. I apologize for any belittling. It is not my intent, but I do see a repeat theme. People thing in single products/projects, not breaking down things into their multiple technologies. That's all I meant by "artificially limiting." > Even if you think you're right, leave some room for the > possibility you're not. It has nothing to do with right/wrong. There is just this farce out there that you must have ADS or every native Windows Server 2003 interface to have quality Windows client management. Various teams, including Samba, have done a wonderful job of reverse engineering many. But the reality is that if you can avoid deploying services that require MS' sprawling (and sometimes self-incomaptible) schema, then you don't need native MS ADS DCs. Enterprises do it all-the-time. > People always need some room in arguments, > unless you want to corner them. > And I'm sure that's not your intent anyway. I _did_ ask the questions, what is ... - ADS? - MS (schema) LDAP? It goes to the heart of the viewpoints and dicussion. Especially for components that are not Samba, but most people only look at for _limited_ Samba use. E.g., MS Kerberos _only_ for authentication of Samba as a member server in a MS ADS DC controller domain (NOT ;-). UNIX/Linux Kerberos servers can do _far_more_ than that, even for 200x/XP clients. Sometimes I think the best marketing done for Windows and Microsoft products is by UNIX/Linux people because they don't even know what services and capabilities are actually offered by UNIX/Linux platforms - be it open source, commercial, etc... ;->

2 4

Re: Fix passwd/shadow/group files?
by Bryan J. Smith <b.j.smith＠ieee.org> 18 Jul '05

18 Jul '05

From: Les Mikesell <lesmikesell(a)gmail.com> > The problem is that nearly all of the people are windows users > that need samba accounts to work in addition to ftp/ssh. So? I've been authenticating Samba against NIS servers since the mid-'90s. I've even used NIS to distribute my smbpasswd files. See "Samba Unleashed," Appendix A (Solaris). ;-> [ NOTE: The book is 5 years old now, Samba 2.0 was latest. ] I wanted to put in more, but the main author (and my largest professional critic) wanted me to keep the NIS/NFS compatibility down because the rest of the book didn't address it. > Some maintain web content, some are customer support that need > write access to the ftp server and another set does some > development and testing on a different box. At various times > in the past, some of the boxes were solaris and freebsd. So? NIS is _universal_ to just about any UNIX flavor. Almost every UNIX C Library supports checking against it. Some include more modular options, like NSSwitch for telling it whether or not to check against NIS maps. > Now they are all Linux and I'm using smb authentication against > a windows domain controller but still create the accounts for each > permitted user manually. Dude ... 1) I specifically asked you if you had an true MS ADS DC. 2) I mentioned MS Services for UNIX (SFU) Dude, if you had a true MS ADS DC and were already authenticating Samba against it, you _should_also_ use SFU to share out NIS from the same. Now you just control your netgroups at your MS ADS DC. Furthermore, you can even setup true UNIX/Linux NIS "slave" servers to SFU, just like you can setup UNIX/Linux BIND "secondary" DNS servers to MS ADS-integrated DNS. That way if your MS ADS DC tanks, you're not down, because you still have UNIX/Linux DNS/NIS. > Can NIS/netgroups mesh with samba authentication against a > windows domain or would I have to use LDAP for better > integration? Think of NIS as "flat file" like old CIFS (except without the broadcast non-sense). Whereas CIFS moved the Reigstry-SAM password DB network-wide, used NT LAN Manager authentication and introduced WINS as a name resolution service, NIS basically does the same for _any_ UNIX files. You don't even need DNS. You can even use pGINA to replace your NT/200x/XP login to authenticate against other servers. I used to do similar with NISGINA back in the '90s (before MS ADS was even an option for Windows networks). GINA is NT's graphical login/authentication system when you logon. Now that MS has gotten serious, you can just use SFU on your MS ADS DC _directly_! Now you're hosting maps, and ensuring ADS objects _match_ those of NIS maps. Alternatively, if you're worried about security, you can use Kerberos for your password store (instead of NIS hashes in passwd). Now that gets a little more client-specific, but you _can_ use MS ADS' Kerberos to provide a "one-way trust" down to a Keberos realm. > Actually, I guess the next integration will be with Active Directory. Wait! Are you CIFS PDC/BDCs or ADS DCs? If you are the former, you _can_ switch _away_ from CIFS altogether! Not only does Samba 2.2+ provide _full_ CIFS replacement, but you can setup Samba 3.0+ as a BDC, mirror the existing, native CIFS PDC, and then _easily_ promote it to a PDC! Once your PDC is Samba, then it's cake to do NIS. If you already made your Network ADS' bitch, then just get MS SFU. Trust me on this, it makes life 100x easier! I wouldn't be surprised if management thinks UNIX/Linux "sucks" because the UNIX/Linux network is setup like crap, and not because it's not capable. > This company has been acquired and the corporate parent is in the > process of converting their domains now and will be including the > users at this location. Just FYI ... Once you ADS, you're _always_ going to be Microsoft-controlled. Samba will _never_ reverse engineer all of Microsoft's LDAP schema. I know MS ADS is required for a lot of new services. In such case, consider segmenting, maintaining and sychronizing the MS ADS to Red Hat Directory Server (fka Netscape Directory Server, NsDS). Florida Institute of Technology's (FIT's) "acctsync" is a ADS DC-side service designed to retrieves any changes or sends any updates (like password) back to their "master" NsDS tree (acctsync also now supports OpenLDAP, although limitedly). FIT did this because back in 1999, when Windows 2000 starting infiltrating their network, they did _not_ want to put UNIX/Linux reliability at the mercy of MS ADS. They were already running a full LDAP tree with NsDS, and even if they were still using legacy NIS, SFU 1.0 didn't offer a good NIS/NFS service yet (that wasn't really until 3.0 -- current version is 3.5 and _free_). You better decide soon whether or not you're going to put your entire network at the mercy of MS ADS, or if you want to maintain some anonymous control. You really need an independent architect to come in and make your life easier. Because it seems your department isn't aware of all your interoperability options. I'm sure your management must think that Windows is 100x easier to support than UNIX/Linux because of your current setup. I mean, NIS is circa 1982 (yes, _82_) UNIX design, and it would solve your problem quite nicely. -- Bryan J. Smith mailto:b.j.smith@ieee.org

4 8

Re: [CentOS] Re: Fix passwd/shadow/group files? -- network architecture is always piecemeal
by Bryan J. Smith 18 Jul '05

18 Jul '05

From: Feizhou > I know what a Kerberos authentication system is. > You mean a core component in Samba 3.0's functionality as an ADS client. You're still artificially limiting your understanding. Kerberos (with the MS extensions in the case of 200x/XP) is how objects authenticate each other and grant tickets for access in a Kerberos realm. Samba can use Kerberos how it sees fit. As a client/member server (with MS Extensions) to native MS ADS DCs, or to 200x/XP clients in the absence of native MS ADS DCs. The issue is when you have native MS ADS DCs, because Samba doea not understand MS ADS DC-to-DC replication. Otherwise, the authentication process to clients is no different. But that's only authentication. Again, stop thining "aggregate," think naming, directory, authentication and file services individually.

2 1

which rpm has libnss_files.a
by Robin Mordasiewicz 18 Jul '05

18 Jul '05

I need the file libnss_files.a for x86_64 Centos-3 Which rpm has this file. --

3 5

Re: Fix passwd/shadow/group files? -- Samba is not an enterprise ? irectory solution ...
by Bryan J. Smith 18 Jul '05

18 Jul '05

From: Feizhou > Yes, I was wondering whether you were trying to say that Samba > could do the extra cruff MS threw into their > Kerberos/LDAP/DNS thingamich. ? Microsoft uses SRV records in DNS. That was actually a _good_ move. Now their DNS-integrated ADS is another story. Although I do have to say the current, split dhcpd, named, nmbd strategy in the open source world is rather attrocious for private, enterprise network management. But their extensions to Kerberos, that was questionable. But _yes_, it has been documented, per their terms with MIT - even if delayed 2 years. Kerberos implementations for UNIX/Linux, which Samba uses, _does_fully_ support the extensions. This has *0* to do with Samba, although Samba 3.0 can integrate with late BIND8.2 and BIND9 w/SRV, as well as KDCs that also do the MS Kerberos extensions. I think you need to _stop_ attributing these things as Samba, there are other, piecemeal efforts involved. > So not Samba 3.0 + non-MS Kerberos New Kerberos/KDC implementations _support_ MS Kerberos. > + non-MS LDAP But what "MS LDAP"? LDAP is simply but a store! Saying LDAP is like saying XML. It is _not_ an end-usable standard, but standard ways of representing/accessing things. What is used, and if that is a standard, that's what matters. Samba 3.0 _can_ represent many things via SMB RPC to Windows clients and servers as if native. It all depends. > but Samba directing all to an ADS DC. Ah,I think your mega-oversimplifying things. You do _not_ need to run a single native MS ADS server on your network to: - Authenticate Windows clients via MS Kerberos (let alone with pGINA to standard Kerberos 5) - Serve out SAM and other MS schema from its LDAP, the ones that have been documented - Handle SMB signing and other protocol features (even ones that are mega-buggy in MS' own implementations) At this point, Samba 3.0 is a _better_ SMB service for Windows 2000 than Windows Server 2003. Microsoft has attested that it recommends only Windows XP Pro clients for full ADS 2003 support. Ziff-Davis testing has shown this to be true. Samba automagically optimizes for the client that is connecting, with Microsoft giving up on performance/features on anything pre-NT5.1 (XP/2003).

1 0

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