Discuss July 2005

discuss@lists.centos.org

190 participants
231 discussions

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

Java
by Lee w 18 Jul '05

18 Jul '05

Hi everyone, I'm a newbie to centos and having trouble upgrading java's jdk1.4 to jdk1.5. I assume I have to get the jdk from jpackage, but I'm having trouble locating it, let alone finding any instructions on how to upgrade. Much appreciated if anyone can help. Thanks!

6 8

pwc kernel module...
by Gilles CHAUVIN 17 Jul '05

17 Jul '05

Hi, I'm just curious about whether some people here were able to make their webcam work under CentOS 4 using the pwc module (with the stock kernel) ? Mine is a PCVC730K (ToUcam Fun) that I would like to connect to my private webserver but, as soon as I connect it, the system freeze (at least not the whole system but the current console, that's weird). Is there something particular to do to make it work or is it just impossible ? Thanks. Gilles.

1 0

Re: Fix passwd/shadow/group files? -- Samba is not an enterprise directory solution ...
by Bryan J. Smith <b.j.smith＠ieee.org> 17 Jul '05

17 Jul '05

From: "Bryan J. Smith <b.j.smith(a)ieee.org>" > So? I've been authenticating Samba against NIS servers since > the mid-'90s ... > You can even use pGINA to replace your NT/200x/XP login to > authenticate against other servers ... > If you are the former, you _can_ switch _away_ from CIFS altogether! > Samba will _never_ reverse engineer all of Microsoft's LDAP schema ... > 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 want to point out one thing. Understand Samba is a collection of services designed of and for CIFS/SMB. It is _not_ a complete "enterprise directory solution." Samba includes: - A Legacy Registry-SAM compatible password store - A Legacy NetBIOS-WINS naming service and protocol - A Legacy NTLM (NT LAN Manager) authentication protocol And then "wraps into" traditional UNIX services like UNIX resolver (DNS, NIS, NSSwitch, etc...), UNIX authentication (files, NIS, PAM, LDAP, etc...), etc... Newer versions of Samba 2.2 include: - MS ADS subset schema for LDAP (OpenLDAP often used) And Samba 3.0 also introduces: - SASL authentication with Kerberos stores (either MS ADS Kerberos or a MS'ized UNIX Kerberos client/KDC services). Samba strives to be a "drop in replacement" for a native Windows DC and file server, including naming (browser) and authentication. But you do _not_ have to use Windows-centric naming or authentication. You can build a network where you either are UNIX/Linux NsDS/OpenLDAP "tree'd" with or without Kerberos, possibly authenticating against native MS ADS DCs or even Samba emulating ADS DCs, or maybe using pGINA on the clients, or you can even have a completely segmented NsDS/OpenLDAP tree/network from native MS ADS network, and use some synchronization between the two. Samba itself is definitely _not_ a UNIX client designed service. And even if you have native MS ADS deployed, you should be running services on the DCs to present UNIX-like interfaces for authentication, naming, etc... on the server, not trying adhoc, manual, kludge in things. And if you're old MS CIFS/PDC, get off of it. Get your network to NsDS (now Red Hat Directory Server) before it's too late -- even if just for your UNIX portion. Or at least introduce 23+ year-old NIS for things. Golden Rule: The _client_ is always right. Always present the _native_ interfaces of the client OS from a server when it comes to: 1) naming 2) directory/store 3) authentication 4) file services Whether you are a true UNIX, e.g., DNS/NIS, NIS, hash, NFS (NIS) DNS/NIS, NIS, Kerberos, NFS (NIS-Kerberos) NIS+, NIS+, RSA, NFS (NIS+) DNS, LDAP, RSA, NFS (Sun One) DNS, LDAP, hash, NFS (LDAP) DNS, LDAP, SASL/Kerberos, NFS (LDAP-SASL/Kerberos) Or maybe a Windows, e.g., NetBIOS/WINS, SAM, NTLM, SMB (CIFS) DNS, MS LDAP, MS Kerberos, SMB (ADS) Or maybe even a Novell, e.g., SAP, Bindery, hash/RSA, NCP (Bindery) NLSP, X.500/DAP, RSA, NCP (NDS aka eDirectory) You should interface with your clients with what _they_ expect, not what your "back-end" is by default. -- Bryan J. Smith mailto:b.j.smith@ieee.org

3 11

CentOS source code for a kernel rebuild
by G Gambill 17 Jul '05

17 Jul '05

Where does Centos expect to find the source for a kernel rebuild??? TIA George

2 1

Re: [CentOS] Logitech Marble Mouse on CentOS 4
by Angelo Machils 17 Jul '05

17 Jul '05

Op 17-jul-2005, om 14:00 heeft centos-request(a)centos.org het volgende geschreven: > Message: 6 > Date: Sat, 16 Jul 2005 07:51:36 -0500 > From: Johnny Hughes <mailing-lists(a)hughesjr.com> > Subject: Re: [CentOS] Logitech Marble Mouse on CentOS 4 > To: CentOS ML <centos(a)centos.org> > Message-ID: <1121518296.14097.191.camel(a)myth.home.local> > Content-Type: text/plain; charset="us-ascii" > > On Sat, 2005-07-16 at 14:41 +0200, Angelo Machils wrote: > >> Hello there! >> >> I just bought this trackball and connected it to a CentOS 4 box. I >> googled on how to edit xorg.conf for the 2 scrollbuttons, and they >> work while using this section: >> >> Section "InputDevice" >> Identifier "Mouse0" >> Driver "mouse" >> Option "Protocol" "ExplorerPS/2" >> Option "Device" "/dev/input/mice" >> Option "Emulate3Timeout" "50" >> Option "Buttons" "7" >> Option "ZAxisMapping" "6 7" >> Option "Emulate3Buttons" "on" >> EndSection >> >> But then the left button is for scrolling up, and the right for >> scrolling down. How can I reverse this?? I have tried several >> sections from the internet, but most have the same result or don't >> work at all. >> >> Thanks in advance for any help and/or tips. >> >> Angelo >> > > How about > > Option "ZAxisMapping" "7 6" > Yes, one would expect this logical change to work. But it has the same result as "6 7"....... Regards, Angelo

1 0

← Newer
1
...
9
10
11
12
13
14
15
...
24
Older →

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 2005