Hi,
I need to set up a small server for a group of ~10 employees (all using Windows 2000/XP, used to use a windows 2000/exchange setup). I have a linux server already running CentOS 4, so I'd like to do all I can with this. I thought about using Samba for file/print sharing and OpenXchange (commercial version) to have a nice collaborative/mail/calendar/etc server. Of course, it would probably be the dhcp and internal DNS server.
I started reading the Samba doc, but it is rather long. I planned on using this server as a PDC so that it is not too different from using their former windows 2000 server. I'll be managing this server, which is currently a staging server for web development (php/mysql/cvs).
Anyone has a opinion on this, or better ideas? My backups will be based on utilities and mondorescue, kept on a internal (cold-swap drawer) hard-drive that I would take every week (2-drawers rotation).
Any recommendations welcome, will provide more details if needed.
TIA,
Ugo Bellavance wrote:
Hi,
I need to set up a small server for a group of ~10 employees (allusing Windows 2000/XP, used to use a windows 2000/exchange setup). I have a linux server already running CentOS 4, so I'd like to do all I can with this. I thought about using Samba for file/print sharing and OpenXchange (commercial version) to have a nice collaborative/mail/calendar/etc server. Of course, it would probably be the dhcp and internal DNS server.
I started reading the Samba doc, but it is rather long. I plannedon using this server as a PDC so that it is not too different from using their former windows 2000 server. I'll be managing this server, which is currently a staging server for web development (php/mysql/cvs).
Anyone has a opinion on this, or better ideas? My backups will be based on utilities and mondorescue, kept on a internal (cold-swap drawer) hard-drive that I would take every week (2-drawers rotation).
Any recommendations welcome, will provide more details if needed.
TIA,
Open Filer? I haven't used it but it's based on CentOS:
www.openfiler.com
--Ajay
Ajay Sharma ssharma@revsharecorp.com wrote:
Open Filer? I haven't used it but it's based on CentOS: www.openfiler.com
Unfortunately, it doesn't provide the authentication/authorization aspect that he needs. He'd need a 2nd server for that.
But if he doesn't mind setting up 2 servers, a CentOS + FDS 7.1 server and an OpenFiler 1.1 server would be a nice combo.
Bryan J. Smith wrote:
Ajay Sharma ssharma@revsharecorp.com wrote:
Open Filer? I haven't used it but it's based on CentOS: www.openfiler.com
Unfortunately, it doesn't provide the authentication/authorization aspect that he needs. He'd need a 2nd server for that.
This looks like an interesting project. The problem with it is that it is a whole distro, so I can't have auth on the same server?
But if he doesn't mind setting up 2 servers, a CentOS + FDS 7.1 server and an OpenFiler 1.1 server would be a nice combo.
Nah... unless I find how to get xen working and I run 2 os on one server, there isn't enough budget to buy another server.
Ugo Bellavance wrote:
Open Filer? I haven't used it but it's based on CentOS: www.openfiler.com
Unfortunately, it doesn't provide the authentication/authorization aspect that he needs. He'd need a 2nd server for that.
This looks like an interesting project. The problem with it is that it is a whole distro, so I can't have auth on the same server?
nothing stopping you from actually ssh'ing in and setting up openldap if you like.. on the same box. But the gui frontend for openfiler, at this stage, will not help you with the process.
- K
On Tue, 2005-12-06 at 05:31, Karanbir Singh wrote:
Ugo Bellavance wrote:
Open Filer? I haven't used it but it's based on CentOS: www.openfiler.com
Unfortunately, it doesn't provide the authentication/authorization aspect that he needs. He'd need a 2nd server for that.
This looks like an interesting project. The problem with it is that it is a whole distro, so I can't have auth on the same server?
nothing stopping you from actually ssh'ing in and setting up openldap if you like.. on the same box. But the gui frontend for openfiler, at this stage, will not help you with the process.
It would be a great addition to that project though. Or to the Centos-based SMEserver if you add NFS too. Then you could build one box where you add users and get home directories and use any number of other Linux or windows workstations where anyone could log in with network authentication and have his home directory auto-mounted.
Les Mikesell wrote:
On Tue, 2005-12-06 at 05:31, Karanbir Singh wrote:
Ugo Bellavance wrote:
Open Filer? I haven't used it but it's based on CentOS: www.openfiler.com
Unfortunately, it doesn't provide the authentication/authorization aspect that he needs. He'd need a 2nd server for that.
This looks like an interesting project. The problem with it is that it is a whole distro, so I can't have auth on the same server?
nothing stopping you from actually ssh'ing in and setting up openldap if you like.. on the same box. But the gui frontend for openfiler, at this stage, will not help you with the process.
It would be a great addition to that project though. Or to the Centos-based SMEserver if you add NFS too. Then you could build one box where you add users and get home directories and use any number of other Linux or windows workstations where anyone could log in with network authentication and have his home directory auto-mounted.
NFS support has been in OpenFiler as long as I can remember.
As is ftp, webdav and smb.
On Tue, 2005-12-06 at 08:11, Karanbir Singh wrote:
Les Mikesell wrote:
On Tue, 2005-12-06 at 05:31, Karanbir Singh wrote:
Ugo Bellavance wrote:
Open Filer? I haven't used it but it's based on CentOS: www.openfiler.com
Unfortunately, it doesn't provide the authentication/authorization aspect that he needs. He'd need a 2nd server for that.
This looks like an interesting project. The problem with it is that it is a whole distro, so I can't have auth on the same server?
nothing stopping you from actually ssh'ing in and setting up openldap if you like.. on the same box. But the gui frontend for openfiler, at this stage, will not help you with the process.
It would be a great addition to that project though. Or to the Centos-based SMEserver if you add NFS too. Then you could build one box where you add users and get home directories and use any number of other Linux or windows workstations where anyone could log in with network authentication and have his home directory auto-mounted.
NFS support has been in OpenFiler as long as I can remember.
As is ftp, webdav and smb.
I meant that SMEserver needs NFS. It already has the SMB server and web-based user management suitable for windows clients. I think you can drop in the stock Centos RPMs on the version 7 beta to add it back but then you still need network authentication for Linux/unix clients.
Les Mikesell wrote:
On Tue, 2005-12-06 at 08:11, Karanbir Singh wrote:
Les Mikesell wrote:
On Tue, 2005-12-06 at 05:31, Karanbir Singh wrote:
Ugo Bellavance wrote:
> Open Filer? I haven't used it but it's based on CentOS: > www.openfiler.com
Unfortunately, it doesn't provide the authentication/authorization aspect that he needs. He'd need a 2nd server for that.
This looks like an interesting project. The problem with it is that it is a whole distro, so I can't have auth on the same server?
nothing stopping you from actually ssh'ing in and setting up openldap if you like.. on the same box. But the gui frontend for openfiler, at this stage, will not help you with the process.
It would be a great addition to that project though. Or to the Centos-based SMEserver if you add NFS too. Then you could build one box where you add users and get home directories and use any number of other Linux or windows workstations where anyone could log in with network authentication and have his home directory auto-mounted.
NFS support has been in OpenFiler as long as I can remember.
As is ftp, webdav and smb.
I meant that SMEserver needs NFS. It already has the SMB server and web-based user management suitable for windows clients. I think you can drop in the stock Centos RPMs on the version 7 beta to add it back but then you still need network authentication for Linux/unix clients.
Guys, the server is already a CentOS server, so I would rather not have to re-install an OS.
Thanks,
On Tue, 2005-12-06 at 08:30, Ugo Bellavance wrote:
I meant that SMEserver needs NFS. It already has the SMB server and web-based user management suitable for windows clients. I think you can drop in the stock Centos RPMs on the version 7 beta to add it back but then you still need network authentication for Linux/unix clients.
Guys, the server is already a CentOS server, so I would rather not have to re-install an OS.
Sorry - the OpenFiler and SMEserver are both based on the CentOS RPMs and are appliance-like to the point that it really would be easier to re-install them than to set up some individual applications by hand. Unfortunately they don't quite meet your needs as-is and modifying an already heavily-modified OS is not fun.
Les Mikesell wrote:
NFS support has been in OpenFiler as long as I can remember.
As is ftp, webdav and smb.
I meant that SMEserver needs NFS. It already has the SMB server and web-based user management suitable for windows clients. I think you can drop in the stock Centos RPMs on the version 7 beta to add it back but then you still need network authentication for Linux/unix clients.
You seem to be confused between openfiler and smeserver. They are not the same thing.
On Tue, 2005-12-06 at 09:08, Karanbir Singh wrote:
Les Mikesell wrote:
NFS support has been in OpenFiler as long as I can remember.
As is ftp, webdav and smb.
I meant that SMEserver needs NFS. It already has the SMB server and web-based user management suitable for windows clients. I think you can drop in the stock Centos RPMs on the version 7 beta to add it back but then you still need network authentication for Linux/unix clients.
You seem to be confused between openfiler and smeserver. They are not the same thing.
I know that. Perhaps you didn't read all of my previous message when you responded. This part in particular:
"It would be a great addition to that project though. Or to the Centos-based SMEserver if you add NFS too."
Perhaps that was badly worded. I meant that adding LDAP to either or both of OpenFiler and SMEserver would be great so you could do all user-related setup in one place for any number of workstations. In the SMEserver case you get email and local/samba user management but not NFS. I'd like to see a distribution that a small/medium sized organization could drop on one server-class box and cover everything that needs individual setup, permitting any number of linux/unix/osx/windows clients to be installed on the network with no special setup yet allow anyone to log in and see their files and get email. Between SMEserver, OpenFiler, and the LDAP directory server, all the parts are there but they don't quite fit together yet.
Karanbir Singh mail-lists@karan.org wrote:
nothing stopping you from actually ssh'ing in and setting up openldap if you like.. on the same box. But the gui frontend for openfiler, at this stage, will not help you with the process.
Doh! Yes, a good and obvious point. My apologies.
Bryan J. Smith wrote:
But if he doesn't mind setting up 2 servers, a CentOS + FDS 7.1 server and an OpenFiler 1.1 server would be a nice combo.
Hi Bryan.
One question... why would you choose FDS 7.1 server (which the site lists as a "Legacy Release") over FDS 1.0? I'm just getting ready to start playing in the FDS sandbox, so I'm interested in what you have to say about it.
Thanks!
Barry
"Barry L. Kline" blkline@attglobal.net wrote:
Hi Bryan. One question... why would you choose FDS 7.1 server (which the site lists as a "Legacy Release") over FDS 1.0? I'm
just
getting ready to start playing in the FDS sandbox, so I'm interested in what you have to say about it.
At this time, I (as in "me") would personally choose 7.1, because I'm already familiar with it, it's tools, etc...
FDS 1.0 (which should be considered "7.2") could be just fine. I just haven't used it personally.
Ugo Bellavance ugob@camo-route.com wrote:
I started reading the Samba doc, but it is rather long.
Of course. ;->
Samba has settings to emulate just about every detail of any release of Server Message Block (SMB) from old LAN Manager to Windows Server 2003. Microsoft's "canned," server-wide settings in their server versions are usually an issue for various clients.
Hence why most enterprises with SMB experts prefer Samba over stock SMB in Windows Server.
I planned on using this server as a PDC so that it is not too different from using their former windows 2000 server.
<anal> FYI, the term Primary Domain Controller (PDC) is deprecated because it refers to the legacy CIFS NT 4.0 term. We typically call modern CIFS/SMB, including ActiveDirectory Services (ADS) integration, as a Domain Controller (DC). Although I noted that the more legacy Samba docs still call it a PDC. </anal>
Note that newer DC services aren't just Samba. Samba just provides the Windows client Remote Procedure Call (RPC) services to the Windows clients when they access it as a file server. Samba can authenticate and authorize against other services.
If you start reading a lot of Windows 2000 / ADS / Samba schtuff, you're going to see people talking about MS Kerberos and native Windows DC integration. That _only_ applies when you are integrating Samba servers with _native_ ADS DC servers (as you've heard me say before, "making UNIX ADS' bitch"). In your case, you're not using a native Windows ADS DC, so Samba is the authority.
How you wish to maintain authentication and directory services is up to you. The Samba 3.0 By Example book gives you a lot of "cookbook methods" to setting up LDAP Schema for Windows clients. You can choose to do such if you wish. In general, there is a _massive_ "learning curve" associated with this, because you have to understand how Windows clients really work at the authentication, directory and file services level -- as well as how UNIX does.
I'll be managing this server, which is currently a staging server for web development (php/mysql/cvs).
Oh. Do you really need SMB then? Should they be doing CVS or Subversion/WebDAV-DeltaV check-ins instead?
Anyone has a opinion on this, or better ideas?
Well, if you don't have native Windows ADS servers, then it's actually pretty easy to do. Samba can and will emulate a lot of different RPC services for the Windows clients. Tweaking those settings will be all you'll need to do.
How you handle the directory services is up to you -- you can even just use local UNIX accounts (although I don't recommend that for future growth and more servers). Years ago I would have just used NIS (with Kerberos if I needed authentication security), but since NsDS 7.1, now FDS 7.1, became available earlier in the year, I've been recommending it (with or without Kerberos, your choice). Especially with the multi-master replication.
The nice thing about building a network with NsDS is that if your organization should force native Windows ADS on you, you can still keep your authentication and control segmented, while synchronizing with ADS accounts.
My backups will be based on utilities and mondorescue,
Be careful with Mondo Rescue. Hugo's a good guy, but his stuff tends to not work on all systems -- just a fact that systems differ and he can't test for everything.
kept on a internal (cold-swap drawer) hard-drive that I would take every week (2-drawers rotation).
As long as you are keeping the disks active regularly, then that's okay. Although longer-term storage (3+ months) really should go to a media like DVD-R, or tape if you can afford it.
Any recommendations welcome, will provide more details if needed.
The scope -- number of servers, types of users, why you need SMB and/or NFS (if you have UNIX desktops) access, CVS or Subversion details, etc...
Bryan J. Smith wrote:
Ugo Bellavance ugob@camo-route.com wrote:
I started reading the Samba doc, but it is rather long.
Of course. ;->
Samba has settings to emulate just about every detail of any release of Server Message Block (SMB) from old LAN Manager to Windows Server 2003. Microsoft's "canned," server-wide settings in their server versions are usually an issue for various clients.
Hence why most enterprises with SMB experts prefer Samba over stock SMB in Windows Server.
Ok
I planned on using this server as a PDC so that it is not too different from using their former windows 2000 server.
<anal> FYI, the term Primary Domain Controller (PDC) is deprecated because it refers to the legacy CIFS NT 4.0 term. We typically call modern CIFS/SMB, including ActiveDirectory Services (ADS) integration, as a Domain Controller (DC). Although I noted that the more legacy Samba docs still call it a PDC. </anal>
I knew that, but this is the terms they use in the Samba doc, probably because Samba can't emulate all the features of a DC.
Note that newer DC services aren't just Samba. Samba just provides the Windows client Remote Procedure Call (RPC) services to the Windows clients when they access it as a file server. Samba can authenticate and authorize against other services.
Yup.
If you start reading a lot of Windows 2000 / ADS / Samba schtuff, you're going to see people talking about MS Kerberos and native Windows DC integration. That _only_ applies when you are integrating Samba servers with _native_ ADS DC servers (as you've heard me say before, "making UNIX ADS' bitch"). In your case, you're not using a native Windows ADS DC, so Samba is the authority.
Ok
How you wish to maintain authentication and directory services is up to you. The Samba 3.0 By Example book gives you a lot of "cookbook methods" to setting up LDAP Schema for Windows clients. You can choose to do such if you wish. In general, there is a _massive_ "learning curve" associated with this, because you have to understand how Windows clients really work at the authentication, directory and file services level -- as well as how UNIX does.
Hmmm, and I don't know LDAP very well... I have started reading the oreilly book about it, but couldn't figure out how it looked/felt/worked in practice :(.
I'll be managing this server, which is currently a staging server for web development (php/mysql/cvs).
Oh. Do you really need SMB then? Should they be doing CVS or Subversion/WebDAV-DeltaV check-ins instead?
Well, there will be a few programmers on this server, but also the direcor, the secretary, a project manager, so they'll obviously need network shares, and, of course, network printing. On question that I have about Samba and printing: Do the printers need to have drivers for linux, if only the windows clients will print, or having windows drivers is enough?
Anyone has a opinion on this, or better ideas?
Well, if you don't have native Windows ADS servers, then it's actually pretty easy to do. Samba can and will emulate a lot of different RPC services for the Windows clients. Tweaking those settings will be all you'll need to do.
Ok
How you handle the directory services is up to you -- you can even just use local UNIX accounts (although I don't recommend that for future growth and more servers). Years ago I would have just used NIS (with Kerberos if I needed authentication security), but since NsDS 7.1, now FDS 7.1, became available earlier in the year, I've been recommending it (with or without Kerberos, your choice). Especially with the multi-master replication.
Hmm, I'll read a bit on it, but I wonder if it isn't overkill...
The nice thing about building a network with NsDS is that if your organization should force native Windows ADS on you, you can still keep your authentication and control segmented, while synchronizing with ADS accounts.
Ok. I doubt that because I'm the only sysadmin, but it can happen...
My backups will be based on utilities and mondorescue,
Be careful with Mondo Rescue. Hugo's a good guy, but his stuff tends to not work on all systems -- just a fact that systems differ and he can't test for everything.
I know Hugo a lot. I can't say I like his style/attitude/product 100% but it works on this specific system. And if doesn't work as a bare-metal recovery system, it is easy to restore (.iso on a hard drive). I agree that I would hesitate to rely on this on a new system, since I don't think there has been a new version of mindi/mondo for months.
kept on a internal (cold-swap drawer) hard-drive that I would take every week (2-drawers rotation).
As long as you are keeping the disks active regularly, then that's okay. Although longer-term storage (3+ months) really should go to a media like DVD-R, or tape if you can afford it.
The drives will be used one week over 2.
Any recommendations welcome, will provide more details if needed.
The scope -- number of servers, types of users, why you need SMB and/or NFS (if you have UNIX desktops) access, CVS or Subversion details, etc...
Number of servers: 1 for the moment. The prod server will be in colo. Types of users: see above. Amount of users: ~ 10 for now, may grow up to 20 max within 24 months. Reason for SMB : file/print sharing. CVS details? What do you need to know exactly? We are using CVS over SSH, Eclipse with ssh keys being the client. The developpers work sometimes in the office, sometimes from home, connected to a vpn (the endpoint is a m0n0wall firewall). The developpers have a Xampp setup on their laptops and develop there, then test on the staging server, then put it in prod. The staging server is also the development MySQL server. I'd like to use OpenXchange to have a mail/calendar/etc solution that can work with current tools (outlook :(). The server is a dual Athlon MP 1800, 1 gB RAM, 3 ware 7006-LP card in RAID 1 with 80 gB PATA HDDs + 1(X2) 200 GB removable hard drive (this server is also a backup server for a few servers for now, but this will probably change.
Please let me know if you need more details.
Thanks for your input ;).
On 12/6/05, Ugo Bellavance ugob@camo-route.com wrote:
On question that I have about Samba and printing: Do the printers need to have drivers for linux, if only the windows clients will print, or having windows drivers is enough?
You have two choices. The default CentOS config is to use Windows drivers only. The config described in "The Official Samba-3 HOWTO and Reference Guide" (under "Advanced Intelligent Printing with PostScript Driver Download") has you use Linux drivers and only a generic PostScript driver for Windows (instead of per-printer drivers). In my experience, the former setup (Windows drivers only) is significantly simpler, and it gives Windows clients better access to printers' features.
Josh Kelley
On Tue, 2005-12-06 at 00:40 -0500, Ugo Bellavance wrote:
I knew that, but this is the terms they use in the Samba doc, probably because Samba can't emulate all the features of a DC.
Actually, it's a good sign of legacy Samba documentation.
Samba has supported PDC/BDC functionality since 2.0, replication compatibility with native NT 4.0 PDC/BDCs as of 2.2+ (i.e., be a BDC to a native NT 4.0 PDC, or a PDC with native NT 4.0 BDCs).
It can _replace_ a native W2K ADS DC as of Samba 3.0, or be its "bitch" -- i.e., a "member server" in a native W2K ADS domain. It can't, however, be a peer DC to a native W2K ADS DC, and it probably never will, at least completely.
In reality, the "controller" functionality of the ADS DC versus the NT 4.0 PDC/BDC is the same. It's still just a big, glorified, network-wide System Account Manager (SAM) database -- really little different than the one in the local registry of a system. In fact, that's the _sole_ "real difference" between a workgroup and a domain -- the SAM** is network-wide for a domain, local for a workgroup**. The replication changes from a master and slaves of the NT 4.0 PDC/BDCs is now peer- replicated in ADS.
[ **NOTE: Ironically enough, this requirement actually has to do more with the poor design assumptions and resulting, often deadly, flaws of the NTFS filesystem. I won't bore you with the details. ;-]
ADS then offers MS-Kerberos for authentication and a sprawling set of schema and, more incompatibly, arbitrary Win32 services integrated with it. It's because of that latter fact that you will probably _never_ be able to use Samba as a DC to various servers that require native Windows W2K ADS (e.g., SQL Server, Exchange, etc...).
A common, and quite _in_correct assumption, is that you need a full ADS domain for Samba to work with Windows XP clients. That is _only_ the requirement when you A) already have a native W2K[3] server providing such or B) you want to use a native Windows service that requires ADS' LDAP store and services (e.g., SQL Server, Exchange, etc...). You can use Samba as a DC without such if not and that includes _removing_ the requirements of MS-Kerberos with the ADS-Samba 3.0 store in an LDAP tree.
Hmmm, and I don't know LDAP very well...
Although the Samba 3 By Example gives you a lot of "cookbook" and "step- by-step" hand-holding to doing such with OpenLDAP, it's still highly recommended that you understand how to administer LDAP.
Then again, if you deploy ADS in anything but a small network, you really should know how to properly deploy ADS. UNIX LDAP and Samba are much more forgiving and can be reconfigured if you make a mistake. ADS and Windows servers need to be wiped and reloaded to make changes sometimes**.
[ NOTE: Again, a lot of these limitations are due to how NTFS was designed, and the resulting issues that places on the NT kernel itself, especially for files from different systems. ]
I have started reading the oreilly book about it, but couldn't figure out how it looked/felt/worked in practice :(.
That's why I always recommended Netscape Directory Server (NsDS) over OpenLDAP, because it makes assumptions, has a GUI management tool designed specifically for it, etc... Once peer replication was added a few years ago, I really stopped looking at OpenLDAP altogether.
Make no mistake, OpenLDAP _is_ powerful. It's very, very flexible, extensible, etc... And it's also a major learning curve if you don't know the first thing about LDAP.
Well, there will be a few programmers on this server, but also the direcor, the secretary, a project manager, so they'll obviously need network shares, and, of course, network printing. On question that I have about Samba and printing: Do the printers need to have drivers for linux, if only the windows clients will print, or having windows drivers is enough?
No, the shares can be "raw."
However, Samba-CUPS SMB-IPP integration can be very, very powerful, including not only the ability to automatically install drivers, but set _proper_ configurations of the printers from the centralized CUPS interface. I.e., when all your printers are Postscript with their own, rich PPD (Postscript Printer Definition) files (or CUPS provides a rich Postscript PPD for a non-PS printer), you can pre-configure the printer and set the defaults for print-queues and they will be set for your Windows users -- all from the CUPS web interface.
E.g., you can configure the memory size, various tray options, etc... just *1* time, then those configurations are set in the printer settings on every Windows client. That way you don't have to go around and do it manually on Windows clients or, worse yet, your users dork with the settings.
The Samba-CUPS integration is a few extra steps the first time, but from then on, you just run 1 command to export the printer driver and its PPD, which is then automagically available and downloaded by the Windows client whenever you setup that network printer. It's no more work than publishing a printer in ActiveDirectory.
Furthermore, the NT (including 2000/XP) print spooler is one of the major reasons why NT crashes. Using the CUPS IPP driver drastically reduces this. Yes, a workaround is to just use the native IPP driver on Windows clients -- but that's not a network printer, but setup as a "local port," not ideal from a management standpoint.
Hmm, I'll read a bit on it, but I wonder if it isn't overkill... Ok. I doubt that because I'm the only sysadmin, but it can happen...
The problem with ADS is the fact that some schmuck in your organization will standardize on an application that requires it. So then your network becomes ADS' bitch.
The key to avoiding that is to have a pre-existing directory service that rules your network, one that can synchronize at least accounts with ADS (if not portions of the LDAP tree, which may be the case for cross- platform apps).
NsDS has always excelled at this over the last few years, and doing the same in OpenLDAP is a major headache. In fact, most of the documentation for OpenLDAP-ADS focuses on making Samba ADS' bitch, instead of making OpenLDAP a peer to ADS. About the only half-way decent tool I've seen for OpenLDAP is FIT's AcctSync.
The drives will be used one week over 2.
What are you doing about long-term retention? Off-site?
Number of servers: 1 for the moment.
Then you can just use local UNIX accounts. No directory server necessary.
The prod server will be in colo. Types of users: see above. Amount of users: ~ 10 for now, may grow up to 20 max within 24 months. Reason for SMB : file/print sharing. CVS details? What do you need to know exactly? We are using CVS over SSH, Eclipse with ssh keys being the client. The developpers work sometimes in the office, sometimes from home, connected to a vpn (the endpoint is a m0n0wall firewall). The developpers have a Xampp setup on their laptops and develop there, then test on the staging server, then put it in prod. The staging server is also the development MySQL server. I'd like to use OpenXchange to have a mail/calendar/etc solution that can work with current tools (outlook :().
I'm very partial to OpenGroupware.ORG (OGo). OGo has a long way to go to be "easily installable," but it's the most flexible and open and _rich_ backend with _server_ side scheduling I've ever seen.
Those are the 2 keys there:
1) open and _rich_ backend 2) _server_ side scheduling
Most are simplistic iCal (little more than FTP/HTTP free/busy) with a web interface, or they are proprietary, MAPI-only (i.e., Outlook-only) interfaces with a web interface.
Both iCal and most "Exchange replacements" then rely 100% on the _client_ to do both processing of the rich store as well as scheduling. There is _little_ intelligence on the server-side. This includes Exchange itself, it's little more than a MAPI and, in more recent versions, a XML-RPC "store" that clients use.
OGo has a web interface and it will do iCal (Apple iCal, Mozilla Calendar, etc...), but it also has Palm.NET (no host required, direct Palm sync), a rich XML-RPC API and then a WebDAV (aka "ZideStore") interface. The last is what its Evolution and Outlook connectors use (Outlook requires an additional MAPI connector, aka "ZideLook", Evolution has its own connector built-in). It then uses it's business logic to _process_ those _different_ stores on the _server_, to both share information between the _different_ stores as well as do things like schedule processing.
E.g., if a Evolution or Outlook client uploads calendaring if via their rich, WebDAV ZideStore, it then gets resolved with data from iCal clients, as well Palm.NET, web users, etc..., and the server resolved schedules are published to all. Same in reverse -- especially for iCal clients. It's not simply a FTP/HTTP "dumping ground" that other clients dumbly download/upload from/to and do their own logic -- that's how the overwhelming majority of iCal servers work.
OpenGroupware.ORG (SKYRiX 4.1) architecture: http://www.opengroupware.org/en/devs/docs/OGoArchitecture.html
It doesn't do the new WebDAV Calendar Access Protocol (CAP) yet, but no systems I know of do -- especially since it's still a draft standard. But CAP is just another WebDAV protocol/store that ZideStore could handle.
BTW, OGo is _only_ the collaboration component. It is not a SMTP/IMAP server.
The server is a dual Athlon MP 1800, 1 gB RAM, 3 ware 7006-LP card in RAID 1 with 80 gB PATA HDDs + 1(X2) 200 GB removable hard drive (this server is also a backup server for a few servers for now, but this will probably change. Please let me know if you need more details. Thanks for your input ;).
Yeah, if you're 1 server, don't worry about a directory service just yet. Just use local accounts to get up'n running for now, then look at a directory service later -- especially when you have more time.
Don't read all the Kerberos/OpenLDAP info on ADS. It's not required to run a Samba domain to XP clients, if you only have Samba servers.
It can _replace_ a native W2K ADS DC as of Samba 3.0, or be its "bitch" -- i.e., a "member server" in a native W2K ADS domain. It can't, however, be a peer DC to a native W2K ADS DC, and it probably never will, at least completely.
Please explain this from the Samba Official Howto:
"Samba-3 is not, and cannot act as, an Active Directory server. It cannot truly function as an Active Directory PDC"
Are you saying that you can integrate Samba 3.0 with a Kerberos server implementation, a LDAP server implementation and dns to give a half-cooked (forget Exchange, blah) but functional ADS DC to host a ADS domain for Windows XP clients to logon to?
Bryan J. Smith wrote:
It can _replace_ a native W2K ADS DC as of Samba 3.0, or be its "bitch" -- i.e., a "member server" in a native W2K ADS domain. It can't, however, be a peer DC to a native W2K ADS DC, and it probably never will, at least
completely.
Feizhou feizhou@graffiti.net wrote:
Please explain this from the Samba Official Howto: "Samba-3 is not, and cannot act as, an Active Directory server. It cannot truly function as an Active Directory PDC"
The Samba documentation is saying the same thing I am.
What I'm clarifying in addition is that you do _not_ need ADS to authenticate Windows clients, use SMB services, etc...
*BUT* it cannot truly act as an ADS server, with all its services, compatibility, etc...
Are you saying that you can integrate Samba 3.0 with a Kerberos server implementation, a LDAP server
implementation
and dns to give a half-cooked (forget Exchange, blah) but functional ADS DC to host a ADS domain for Windows XP clients to logon to?
In what context?
First off, you _can_ authenticate Windows 2000+ clients against Kerberos for various services. Or you can use NTLMv2 instead. You can use SMB signing, or you can disable it. Etc...
But, more directly, if you expect a Windows XP client to work with Samba+Kerberos+LDAP "out-of-the-box" you are greatly _mistaken_. Let me say that again, the "Windows XP _client_ to work ... out-of-the-box."
GOLDEN INSIGHT:
Windows domains and domain controllers (DCs) aren't about the server, they are about the _assumptions_ clients make. Until ADS, the DC functionality was really little more than a network-wise SAM database and a few services. With ADS, there are rich stores.
At login, you're talking about the GINA.
I know that's what everyone wants the _client_ "out-of-the-box," and maybe some of those "most basic" of services that the native XP GINA for ADS will be reverse engineered to the point they will work with Samba+Kerberos+LDAP. But for now, they do not. And it's very likely Samba will _never_ offer the full ADS RPC suite, just enough for the native GINA will be all they can do.
And just in time for Microsoft to release Vista, which will make a whole new set of assumptions of services at the client. ;->
Bryan J. Smith wrote:
Bryan J. Smith wrote:
It can _replace_ a native W2K ADS DC as of Samba 3.0, or be its "bitch" -- i.e., a "member server" in a native W2K ADS domain. It can't, however, be a peer DC to a native W2K ADS DC, and it probably never will, at least
completely.
Feizhou feizhou@graffiti.net wrote:
Please explain this from the Samba Official Howto: "Samba-3 is not, and cannot act as, an Active Directory server. It cannot truly function as an Active Directory PDC"
The Samba documentation is saying the same thing I am.
When you say replace a native W2K ADS DC, I get the impression that you mean it will do what a native W2K ADS DC does.
Are you saying that you can integrate Samba 3.0 with a Kerberos server implementation, a LDAP server
implementation
and dns to give a half-cooked (forget Exchange, blah) but functional ADS DC to host a ADS domain for Windows XP clients to logon to?
In what context?
First off, you _can_ authenticate Windows 2000+ clients against Kerberos for various services. Or you can use NTLMv2 instead. You can use SMB signing, or you can disable it. Etc...
But, more directly, if you expect a Windows XP client to work with Samba+Kerberos+LDAP "out-of-the-box" you are greatly _mistaken_. Let me say that again, the "Windows XP _client_ to work ... out-of-the-box."
Well, when you say _native_, of couse we think 'out-of-the-box'.
GOLDEN INSIGHT:
Windows domains and domain controllers (DCs) aren't about the server, they are about the _assumptions_ clients make. Until ADS, the DC functionality was really little more than a network-wise SAM database and a few services. With ADS, there are rich stores.
At login, you're talking about the GINA.
I know that's what everyone wants the _client_ "out-of-the-box," and maybe some of those "most basic" of services that the native XP GINA for ADS will be reverse engineered to the point they will work with Samba+Kerberos+LDAP. But for now, they do not. And it's very likely Samba will _never_ offer the full ADS RPC suite, just enough for the native GINA will be all they can do.
And just in time for Microsoft to release Vista, which will make a whole new set of assumptions of services at the client. ;->
Then please don't say 'replace a native Windows ADS DC'. It gives the wrong impression if you do not add, oh you can use a mysql server to authenticate if you change the GINA.
On 12/7/05, Bryan J. Smith thebs413@earthlink.net wrote:
Samba has supported PDC/BDC functionality since 2.0, replication compatibility with native NT 4.0 PDC/BDCs as of 2.2+ (i.e., be a BDC to a native NT 4.0 PDC, or a PDC with native NT 4.0 BDCs).
I don't think that that Samba can serve as a PDC to NT 4.0 BDCs (or vice versa); the HOWTO says it's impossible, and the 2.2 release notes make no mention of it.
It can _replace_ a native W2K ADS DC as of Samba 3.0, or be its "bitch" -- i.e., a "member server" in a native W2K ADS domain. It can't, however, be a peer DC to a native W2K ADS DC, and it probably never will, at least completely.
This is incorrect. Samba 3.0 cannot be a native ADS DC; that feature will be added in Samba 4.
ADS then offers MS-Kerberos for authentication and a sprawling set of schema and, more incompatibly, arbitrary Win32 services integrated with it. It's because of that latter fact that you will probably _never_ be able to use Samba as a DC to various servers that require native Windows W2K ADS (e.g., SQL Server, Exchange, etc...).
Another advantage of ADS/change in ADS relative to NT 4.0 is that it uses DNS rather than NetBIOS name resolution and lets you get rid of NetBIOS completely if you wish.
However, Samba-CUPS SMB-IPP integration can be very, very powerful, including not only the ability to automatically install drivers, but set _proper_ configurations of the printers from the centralized CUPS interface. I.e., when all your printers are Postscript with their own, rich PPD (Postscript Printer Definition) files (or CUPS provides a rich Postscript PPD for a non-PS printer), you can pre-configure the printer and set the defaults for print-queues and they will be set for your Windows users -- all from the CUPS web interface.
E.g., you can configure the memory size, various tray options, etc... just *1* time, then those configurations are set in the printer settings on every Windows client. That way you don't have to go around and do it manually on Windows clients or, worse yet, your users dork with the settings.
Can't you do the same thing using raw printing, by configuring the printer in Windows?
Josh Kelley
However, Samba-CUPS SMB-IPP integration can be very, very powerful, including not only the ability to automatically install drivers, but set _proper_ configurations of the printers from the centralized CUPS interface. I.e., when all your printers are Postscript with their own, rich PPD (Postscript Printer Definition) files (or CUPS provides a rich Postscript PPD for a non-PS printer), you can pre-configure the printer and set the defaults for print-queues and they will be set for your Windows users -- all from the CUPS web interface.
E.g., you can configure the memory size, various tray options, etc... just *1* time, then those configurations are set in the printer settings on every Windows client. That way you don't have to go around and do it manually on Windows clients or, worse yet, your users dork with the settings.
Can't you do the same thing using raw printing, by configuring the printer in Windows?
He means when you add a network printer, you don't need to carry the driver cd/disk with you to each Windows PC. Just browse for the printer and the Windows OS on the PC will automatically download the driver files and settings and then you are done.
Can't you do the same thing using raw printing, by configuring the printer in Windows?
Hmm...you meant on a Windows server didn't you?
He means when you add a network printer, you don't need to carry the driver cd/disk with you to each Windows PC. Just browse for the printer and the Windows OS on the PC will automatically download the driver files and settings and then you are done.
On 12/7/05, Feizhou feizhou@graffiti.net wrote:
Can't you do the same thing using raw printing, by configuring the printer in Windows?
Hmm...you meant on a Windows server didn't you?
He means when you add a network printer, you don't need to carry the driver cd/disk with you to each Windows PC. Just browse for the printer and the Windows OS on the PC will automatically download the driver files and settings and then you are done.
No, I meant on a Windows client. You can use a Windows client to install Windows drivers to a Samba print server that's operating in raw mode. Then you can configure the printer driver from the Windows client, and I'm pretty sure that saves the default settings on the Samba server. Then you can point-and-print from Windows (no manual driver installation needed), just as you could if you were using full (non-raw) Samba-CUPS integration.
Josh Kelley
Josh Kelley wrote:
On 12/7/05, Feizhou feizhou@graffiti.net wrote:
Can't you do the same thing using raw printing, by configuring the printer in Windows?
Hmm...you meant on a Windows server didn't you?
He means when you add a network printer, you don't need to carry the driver cd/disk with you to each Windows PC. Just browse for the printer and the Windows OS on the PC will automatically download the driver files and settings and then you are done.
No, I meant on a Windows client. You can use a Windows client to install Windows drivers to a Samba print server that's operating in raw mode. Then you can configure the printer driver from the Windows client, and I'm pretty sure that saves the default settings on the Samba server. Then you can point-and-print from Windows (no manual driver installation needed), just as you could if you were using full (non-raw) Samba-CUPS integration.
Er...those drivers are installed on the Windows client, not the samba server. Bryan's case is rather special. He is not talking about a raw queue but a postscript queue. Since it is postscript, all the Windows clients just need to install a postscript print driver (which of course will be downloaded from the Samba server) and then they are done. The printer settings will have been setup on the Samba server via CUPS as he said.
So, no you cannot do that through a Windows client to a Samba raw print queue. A raw print queue just sends the data direct to the printer. So it can only print ASCII or data in its own printer language. This therefore requires that the Windows client has a driver installed locally and therefore configured locally.
On Wed, 2005-12-07 at 12:59, Feizhou wrote:
No, I meant on a Windows client. You can use a Windows client to install Windows drivers to a Samba print server that's operating in raw mode. Then you can configure the printer driver from the Windows client, and I'm pretty sure that saves the default settings on the Samba server. Then you can point-and-print from Windows (no manual driver installation needed), just as you could if you were using full (non-raw) Samba-CUPS integration.
Er...those drivers are installed on the Windows client, not the samba server. Bryan's case is rather special. He is not talking about a raw queue but a postscript queue. Since it is postscript, all the Windows clients just need to install a postscript print driver (which of course will be downloaded from the Samba server) and then they are done. The printer settings will have been setup on the Samba server via CUPS as he said.
I haven't done this but was under the impression that samba could associate any windows print driver (not just postscript) with a shared printer and it would auto-install the driver on the windows client when the printer was set up there.
Les Mikesell wrote:
On Wed, 2005-12-07 at 12:59, Feizhou wrote:
No, I meant on a Windows client. You can use a Windows client to install Windows drivers to a Samba print server that's operating in raw mode. Then you can configure the printer driver from the Windows client, and I'm pretty sure that saves the default settings on the Samba server. Then you can point-and-print from Windows (no manual driver installation needed), just as you could if you were using full (non-raw) Samba-CUPS integration.
Er...those drivers are installed on the Windows client, not the samba server. Bryan's case is rather special. He is not talking about a raw queue but a postscript queue. Since it is postscript, all the Windows clients just need to install a postscript print driver (which of course will be downloaded from the Samba server) and then they are done. The printer settings will have been setup on the Samba server via CUPS as he said.
I haven't done this but was under the impression that samba could associate any windows print driver (not just postscript) with a shared printer and it would auto-install the driver on the windows client when the printer was set up there.
Yes but not auto configure the printer settings on the Windows client. I have done this before.
Bryan's case of a postscript printer or a printer with a postscript driver on the Samba box means that the printer settings can be set once and for all. (Probably not what you want for a colour printer)
Feizhou feizhou@graffiti.net wrote:
Bryan's case of a postscript printer or a printer with a postscript driver on the Samba box means that the printer settings can be set once and for all.
That's option #3, with the Adobe PS driver. Option #4 does a lot more, no messing with smb.conf at all.
(Probably not what you want for a colour printer)
Why not?
I'm just setting the printer configuration (memory, trays, etc...). Users can still change selections within that configuration (dpi, quality, etc...).
Les Mikesell lesmikesell@gmail.com wrote:
I haven't done this but was under the impression that samba could associate any windows print driver (not just
postscript)
with a shared printer and it would auto-install the driver
on
the windows client when the printer was set up there.
Yes, and that requires some manual setup on the server for each new printer that is not straight-forward. You have to get the string and other files _exact_, and some vendor programs are not exactly built for such redistribution. Typically you have to install on one Windows system, then share it, then grab those files back off, and you finally have just the fileset. Then you've gotta comb through the INF for the strings.
Not fun.
Furthermore, vendor printer drivers tend to conflict with the NT spooler. A few years ago IKON came out and made a serious mess of one of my networks once because the guys went around installing the Lexmark and Ricoh drivers, which instantly conflicted with each other as well as the HP drivers. I caught them by the 5th system, before they destroyed any more.
This is why I advocate either #3 or #4 if you have more than a few printers on a few servers. Using at least Postscript for everything means no inter-vendor mess. It also means that you have *1* driver, and everything becomes a matter of PPDs. With CUPS, you can make most printers look like a Postscript printer.
If you use the CUPS driver for Windows with the CUPS-Samba integration, you do _not_ have to mess with the smb.conf and the printer strings at all! The CUPS driver for Windows lets Windows clients see the CUPS IPP service, and then it uses SMB to download the appropriate PPD (which is administered with _all_ options from the CUPS server itself). The CUPS-Samba integration means you run *1* CUPS command to republish the PPDs -- again, *0* smb.conf editing, setting up printer strings, etc...
On Wed, 2005-12-07 at 15:53, Bryan J. Smith wrote:
If you use the CUPS driver for Windows with the CUPS-Samba integration, you do _not_ have to mess with the smb.conf and the printer strings at all! The CUPS driver for Windows lets Windows clients see the CUPS IPP service, and then it uses SMB to download the appropriate PPD (which is administered with _all_ options from the CUPS server itself). The CUPS-Samba integration means you run *1* CUPS command to republish the PPDs -- again, *0* smb.conf editing, setting up printer strings, etc...
Does this let the client have access to all the printer-specific options (duplex, paper size, input trays, etc.)?
Les Mikesell lesmikesell@gmail.com wrote:
Does this let the client have access to all the printer-specific options (duplex, paper size, input trays, etc.)?
Yes!
It sends down the PPD with all that information, and the user can change it on a per print-job basis.
What the CUPS driver for Windows with the CUPS-Samba integration does for you is _match_verbatim_ the PPD configuration between the CUPS server and _all_ Windows clients. That's golden!
It also means that _you_ not only set the defaults, but the printer's _absolute_ configuration, at the at the CUPS server. Not even a local workstation administrator can change them. It prevents some "curious power user" from going in and changing the printer configuration incorrectly, which then causes a printer to sit there and say "insert paper into" whatever tray it physically does _not_ have, especially when it just defaults to the multi-purpose feeder.
You can setup all the trays, types, etc... at the CUPS server, even designating administrators for that printer, etc... No more dorking around with things at the Windows client.
On 12/7/05, Feizhou feizhou@graffiti.net wrote:
Er...those drivers are installed on the Windows client, not the samba server. Bryan's case is rather special. He is not talking about a raw queue but a postscript queue. Since it is postscript, all the Windows clients just need to install a postscript print driver (which of course will be downloaded from the Samba server) and then they are done. The printer settings will have been setup on the Samba server via CUPS as he said.
So, no you cannot do that through a Windows client to a Samba raw print queue. A raw print queue just sends the data direct to the printer. So it can only print ASCII or data in its own printer language. This therefore requires that the Windows client has a driver installed locally and therefore configured locally.
No.
With a Postscript print queue, you upload Windows printer drivers for a generic Postscript printer to the Samba server (probably using the cupsaddsmb script). With a raw print queue, you upload Windows printer drivers for each printer to the Samba server (probably using the Add Printer Wizard).
With a Postscript print queue, a Windows client that tries to print to a Samba printer automatically downloads the appropriate driver. With a raw print queue, the Windows client does the same. In either case, the driver is technically installed locally, but no special effort on the part of the user is required.
With a Postscript print queue, you can configure printer defaults on the server, using CUPS. With a raw print queue, you can configure printer defaults under an administrator account on a client, using the Windows print driver, then it writes those defaults back to the server for others to use.
Raw print queues really don't have the shortcomings in functionality that you seem to be saying they do.
Josh Kelley
Hello Josh,
With a Postscript print queue, you can configure printer defaults on the server, using CUPS. With a raw print queue, you can configure printer defaults under an administrator account on a client, using the Windows print driver, then it writes those defaults back to the server for others to use.
Raw print queues really don't have the shortcomings in functionality that you seem to be saying they do.
How exactly does a Windows generic postscript driver communicate with the cups system on printer settings through samba?
Even the cups postscript driver for windows does not appear to offer that...
On 12/7/05, Feizhou feizhou@graffiti.net wrote:
With a Postscript print queue, you can configure printer defaults on the server, using CUPS. With a raw print queue, you can configure printer defaults under an administrator account on a client, using the Windows print driver, then it writes those defaults back to the server for others to use.
Raw print queues really don't have the shortcomings in functionality that you seem to be saying they do.
How exactly does a Windows generic postscript driver communicate with the cups system on printer settings through samba?
Even the cups postscript driver for windows does not appear to offer that...
I'm confused. I'm afraid that we may have misunderstood each other in the last round or two of emails. If I've misunderstood or communicated poorly, I apologize.
Bryan said that with Postscript queues, you can configure printer settings through CUPS. With Postscript queues, you use a generic Postscript driver for Windows (such as the one provided by CUPS - I didn't mean to imply a distinction between a generic driver and the CUPS driver), and the Postscript driver gets its printer settings from the PPD that you configure through CUPS.
With raw queues, it's my understanding - please correct me if I'm wrong - that the printer drivers run on the client and can store the device mode and printer driver data on the server. In this case, CUPS has no knowledge of any of the settings, and Samba doesn't really understand them either - it treats them as opaque data structures that it provides to Windwos clients upon request.
At any rate, though, it works, and I've found it to be a simpler setup than Postscript queues. YMMV.
Josh Kelley
Josh Kelley wrote:
On 12/7/05, Feizhou feizhou@graffiti.net wrote:
With a Postscript print queue, you can configure printer defaults on the server, using CUPS. With a raw print queue, you can configure printer defaults under an administrator account on a client, using the Windows print driver, then it writes those defaults back to the server for others to use.
Raw print queues really don't have the shortcomings in functionality that you seem to be saying they do.
How exactly does a Windows generic postscript driver communicate with the cups system on printer settings through samba?
Even the cups postscript driver for windows does not appear to offer that...
I'm confused. I'm afraid that we may have misunderstood each other in the last round or two of emails. If I've misunderstood or communicated poorly, I apologize.
Most probably we have misunderstood each other.
Bryan said that with Postscript queues, you can configure printer settings through CUPS. With Postscript queues, you use a generic Postscript driver for Windows (such as the one provided by CUPS - I didn't mean to imply a distinction between a generic driver and the CUPS driver), and the Postscript driver gets its printer settings from the PPD that you configure through CUPS.
ok.
With raw queues, it's my understanding - please correct me if I'm wrong - that the printer drivers run on the client and can store the device mode and printer driver data on the server. In this case, CUPS has no knowledge of any of the settings, and Samba doesn't really understand them either - it treats them as opaque data structures that it provides to Windwos clients upon request.
Nope, the device mode and printer driver data stay on client. raw queue is really just, client sends file over, samba feeds file to raw queue which then feeds the file straight to the printer.
At any rate, though, it works, and I've found it to be a simpler setup than Postscript queues. YMMV.
For a single workstation yes.
For an office with lots of desktops sharing a standard laser, the install a postscript driver ( Windows don't speak postscript, so the postscript driver is convert Windows print data to postscript) on the desktops and then configure the printer settings once on the samba box is really a great help.
With raw queues, it's my understanding - please correct me if I'm wrong - that the printer drivers run on the client
and
can store the device mode and printer driver data on the server.
No, this is completely _wrong_ -- even for native NT/2K[3] servers -- _unless_ the vendor provides such management in their drivers. And then you can get into some really messy setups with multiple vendors *COUGH*Lexmark*COUGH*.
All you can do is "share" the printer files from a native Windows print server, which are from the vendor. It's up to the vendor to offer default settings at the server, which the client inherits. I think you're spoiled with vendor logic, which is fine as long as you're only using 1 vendor's printers on a print server.
In this case, CUPS has no knowledge of any of the settings, and Samba doesn't really understand them either - it treats them as opaque data structures that it provides to Windwos clients upon request.
It doesn't matter what server is, you can have "raw" queues on Windows too. If you have "raw" queues, the server doesn't understand what the client's sending to it.
At any rate, though, it works, and I've found it to be a simpler setup than Postscript queues. YMMV.
I disagree entirely. Maybe that's because you're using the crappy Microsoft Postscript driver. ;->
I always use the CUPS driver and, if its not compatible with the Windows version, the Adobe PS driver. _Never_ that horrendous generic Postscript driver that Microsoft offers.
On Wed, 2005-12-07 at 14:39 -0800, Bryan J. Smith wrote:
With raw queues, it's my understanding - please correct me if I'm wrong - that the printer drivers run on the client
and
can store the device mode and printer driver data on the server.
No, this is completely _wrong_ -- even for native NT/2K[3] servers -- _unless_ the vendor provides such management in their drivers. And then you can get into some really messy setups with multiple vendors *COUGH*Lexmark*COUGH*.
All you can do is "share" the printer files from a native Windows print server, which are from the vendor. It's up to the vendor to offer default settings at the server, which the client inherits. I think you're spoiled with vendor logic, which is fine as long as you're only using 1 vendor's printers on a print server.
---- There is room for misinterpretation of what you are saying and the way other people would believe would occur.
Official Samba documentation - How-TO - states,,,
"Now all the other users downloading and installing the driver the same way (using Point'n'Print) will have the same defaults set for them. If you miss this step, you'll get a lot of help desk calls from your users, but maybe you like to talk to people."
http://samba.org/samba/docs/man/Samba-HOWTO- Collection/classicalprinting.html#prt-modeset
This would appear to be at odds with your statement. I have had no problem propagating default settings to 'client' installs from printers set up via APW/Point and Print on samba servers. ----
In this case, CUPS has no knowledge of any of the settings, and Samba doesn't really understand them either - it treats them as opaque data structures that it provides to Windwos clients upon request.
It doesn't matter what server is, you can have "raw" queues on Windows too. If you have "raw" queues, the server doesn't understand what the client's sending to it.
At any rate, though, it works, and I've found it to be a simpler setup than Postscript queues. YMMV.
I disagree entirely. Maybe that's because you're using the crappy Microsoft Postscript driver. ;->
I always use the CUPS driver and, if its not compatible with the Windows version, the Adobe PS driver. _Never_ that horrendous generic Postscript driver that Microsoft offers.
---- it would be hard to make an argument to use Microsoft's PostScript print driver for anything other than the fact that it is built in.
Craig
Craig White craigwhite@azapple.com wrote:
There is room for misinterpretation of what you are saying and the way other people would believe would occur.
Okay, in the context of comparing this "unofficial hack" of, and I quote ...
"- a valid device mode generated by the driver for the printer (defining things like paper size, orientation and duplex settings). - A complete set of printer driver data generated by the driver. ... Fortunately, most drivers automatically generate the printer driver data that is needed when they are uploaded to the [print$] share with the help of the APW or rpcclient. The generation and setting of a first valid device mode, however, requires some tickling from a client to set it on the Samba server. The easiest means of doing so is to simply change the page orientation on the server's printer. This executes enough of the printer driver program on the client for the desired effect to happen and feeds back the new device mode to our Samba server."
First off, this is _very_subjective_. Remember, there are *2* differing configuration screens to any printer. We're not talking about page orientation, which tray you want by default, etc... We're talking core printer assembly details -- memory, font sets, trays, bays and other options installed. Things I do _not_ want people changing because -- e.g., Tray 4 doesn't exist! -- that type of stuff. ;->
The "device mode" that Samba can store is rather limited. It's not going to help you with more advanced features that can change, which will require you to re-upload your original printer data from Windows again. It's more about page orientation than what trays are configured.
Secondly, and far more relevant, this is _laughable_ compared to a PPD. My response was with regards to how the PPD provides such settings, especially in conjuction with the "unified" approach of CUPS and the CUPS driver for Windows. That's where the CUPS driver and CUPS-Samba integration is better than just using the Adobe PS with a PPD.
You really have to see it in action to understand what it does. For 1-2 printers on a small network, not a big deal. For 5+ printers on an enterprise network -- thank God!
Easy Software Products (ESP) makes money on selling fully supported CUPS solutions because it just works so much better -- for _all_ vendor printers, various clients (especially Windows), etc...
In Windows, to get the same, I have to select *1* vendor, and use only their printers with their management software. Especially for non-Windows clients.
This would appear to be at odds with your statement. I have had no problem propagating default settings to 'client' installs from printers set up via APW/Point and Print on
samba
servers.
Again, not nearly the same level of "control" as a PPD, especially given the fact that it is "unified" with the CUPS server. Even using the Adobe PS driver with a PPD and using it to feed back changes to the share would not be as good.
it would be hard to make an argument to use Microsoft's PostScript print driver for anything other than the fact that it is built in.
Some things just don't mix. ;->
Feizhou feizhou@graffiti.net wrote:
How exactly does a Windows generic postscript driver communicate with the cups system on printer settings
through
samba?
It uses Samba to get the PPDs.
For my prior #3 (Adobe PS driver), it's a crapload easier when all you have to do for any new printer is configure a new Printer string and point to its PPD in the smb.conf. If you have different vendor drivers, you have to deal with figuring out all those different files.
For my prior #4 (CUPS driver, CUPS-Samba), you _never_ have to edit the smb.conf. The CUPS driver on the Windows side knows where to look and how to setup PPDs automagically. And any changes mean the new PPD gets published, etc...
Even the cups postscript driver for windows does not appear to offer that...
We're talking about both: A) How do you configure the Samba server to publish the printer driver, and B) How do you configure the client to use the driver
#1 in my prior discussion does _neither_.
#2-3 in my prior discussion automates A. #3 is less of a bitch for B than #2, because it's the same driver, only the Printer string and PPD changes.
#4 in my prior discussion automates _both_ A and B.
#4 also keeps users from changing options on the printer they should not -- like changing tray options that don't exist and holding up queues as the printer waits for manual intervention.
Josh Kelley joshkel@gmail.com wrote:
No. With a Postscript print queue, you upload Windows printer drivers for a generic Postscript printer to the Samba
server
(probably using the cupsaddsmb script).
Yep, that's option #4. Especially when used with the CUPS driver for Windows.
You can still fetch those PPD files for use with #3, but it requires manual intervention.
With a raw print queue, you upload Windows printer drivers for each printer to the Samba server (probably using the Add Printer Wizard).
Yep. It's a PITA each time you add a printer.
On a smaller network with 1-2 printers, do it once, forget it.
But on larger network, with more printers or -- better yet -- changing printers, it's a Godsend. Especially when you have certain printers choking due to users killing settings, things that you can override (like removing options).
Raw print queues really don't have the shortcomings in functionality that you seem to be saying they do.
Unless you're installing several different printer drivers on a Windows client, and the vendor drivers start conflicting.
Feizhou feizhou@graffiti.net wrote:
Er...those drivers are installed on the Windows client, not the samba server. Bryan's case is rather special. He is not talking about a raw queue but a postscript queue. Since it
is
postscript, all the Windows clients just need to install a postscript print driver (which of course will be downloaded from the Samba server) and then they are done. The printer settings will have been setup on the Samba server via CUPS as he said.
There are basically 4 ways you can setup Windows printer queues:
1. All Manual: Each one "raw" and go around manually installing drivers -- either SMB or an IPP/LPD/JetDirect port
2. Manual and Driver Share: Each one "raw" and setup Samba shares with the printer drivers (with associated settings in smb.conf)
3. CUPS, Postscript and Driver Share: Use CUPS so they are Postscript queues, use the Adobe Postscript driver, and setup Samba shares with the PPDs (with the associated settings in smb.conf)
4. CUPS-Samba, CUPS driver for Windows and Automated PPD Use CUPS so they are Postscript queues, use the CUPS drivers for Windows and use the CPUS-Samba script, which handles automatically publishing any CUPS changes into a fixed location the CUPS driver for Windows knows where to get PPD files for the printers without any manual intervention
#1 gives you manual fits
#2 and #3 has you setup a Samba share with printer info. #3 minimizes the printer setup by letting you merely plop out PPD files into the share. In either case, you _still_ have to edit smb.conf with the exact printer info, or use a separate GUI tool.
#4 takes #3 and puts it on steroids. Instead of using the non-CUPS aware Adobe Postscript driver, which still requires some manual intervention on the client side (like #2), you use the CUPS driver for Windows. Now you manage _everything_ from the CUPS interface, and run *1* command to update the PPDs to the share. The CUPS driver for Windows handles getting everything from the server, including updated PPDs.
Josh Kelley joshkel@gmail.com wrote:
No, I meant on a Windows client. You can use a Windows client to install Windows drivers to a Samba print server that's operating in raw mode. Then you can configure the printer driver from the Windows client, and I'm pretty sure that saves the default settings on the Samba server.
Ahhh, no. It's far more manual to do this, and any changes would have to be manually re-installed on each Windows client.
Then you can point-and-print from Windows (no manual driver installation needed), just as you could if you were using full (non-raw) Samba-CUPS integration.
Not the same at all. Using the Adobe Postscript driver, at the most, you could make it as easy as updating the PPD. But it still won't be as automated.
Feizhou wrote:
However, Samba-CUPS SMB-IPP integration can be very, very powerful, including not only the ability to automatically install drivers, but set _proper_ configurations of the printers from the centralized CUPS interface. I.e., when all your printers are Postscript with their own, rich PPD (Postscript Printer Definition) files (or CUPS provides a rich Postscript PPD for a non-PS printer), you can pre-configure the printer and set the defaults for print-queues and they will be set for your Windows users -- all from the CUPS web interface.
i need some sleep...
Feizhou feizhou@graffiti.net wrote:
He means when you add a network printer, you don't need to carry the driver cd/disk with you to each Windows PC.
It's more than just that.
Even if I load the Adobe Postscript driver** and the vendor PPD (possibly after I've modified the settings to the correct for the printer config), the user could change things (depending on access). They also don't get any new modifications I make at the CUPS server.
**NOTE: On a corporate network, this is a good practice, so you're not going around and installing all sorts of vendor printer drivers, which can conflict. Of course, it means you have to have Postscript printers *OR* CUPS emulating Postscript. The Samba-CUPS with CUPS Windows driver at the client is easist and best, once you set it up on the server.
Just browse for the printer and the Windows OS on the PC
will
automatically download the driver files and settings and
then
you are done.
And best of all, you only have to do this *1* time from CUPS, and then run *1* Samba command to update anytime you make changes (that affect the PPDs).
Bryan J. Smith wrote:
Feizhou feizhou@graffiti.net wrote:
He means when you add a network printer, you don't need to carry the driver cd/disk with you to each Windows PC.
It's more than just that.
Yes, I missed the postscript part.
Josh Kelley joshkel@gmail.com wrote:
I don't think that that Samba can serve as a PDC to NT 4.0 BDCs (or vice versa); the HOWTO says it's impossible, and
the
2.2 release notes make no mention of it.
Then it must be 3.0 that Samba can fully replicate to/from PDC and BDCs. 2.2 (and 2.0 IIRC?) offered the functionality of a PDC or BDC, but only with Samba itself.
This is incorrect. Samba 3.0 cannot be a native ADS DC; that feature will be added in Samba 4.
Note I said "replace." I carefully chose that word. I _clarified_ what I meant in another e-mail.
Another advantage of ADS/change in ADS relative to NT 4.0 is that it uses DNS rather than NetBIOS name resolution and lets you get rid of NetBIOS completely if you wish.
Frankly, I wish they'd move the name services _outside_ of Samba, and to a general layer-2/3 server.
Can't you do the same thing using raw printing, by configuring the printer in Windows?
You'd have to manually maintain the printer drivers, manually setup the PPD (or copy it from an existing), etc... Although this is tolerable with the Adobe Postscript driver, it's still easier to manage it with the Samba-CUPS because everything happens automagically.
One major issue with not using a single printer driver in Windows is that vendor printer drivers of the same type (e.g., more than 1 PCL, more than 1 Postscript, etc...) can conflict**. That's why at least using the Adobe Postscript driver solves that (using the vendor's PPD), at least when you have Postscript drivers (or so emulated at the print server).
Again, Samba-CUPS setup totally removes this issue because _everything_ goes through the CUPS driver. And everything is automated at the server, including the printer config.
-- Bryan
**NOTE: I will leave several, "major" office/printer integrator "unnamed," but they regularly come in and just run the vendor's install programs and have drastically "dorked up" the spoolers on my NT/2K/XP systems in the past.
On Wed, 2005-12-07 at 11:49 -0800, Bryan J. Smith wrote:
Josh Kelley joshkel@gmail.com wrote:
I don't think that that Samba can serve as a PDC to NT 4.0 BDCs (or vice versa); the HOWTO says it's impossible, and
the
2.2 release notes make no mention of it.
Then it must be 3.0 that Samba can fully replicate to/from PDC and BDCs. 2.2 (and 2.0 IIRC?) offered the functionality of a PDC or BDC, but only with Samba itself.
---- No - samba 3.0.x cannot fully replicate to/from PDC/BDC
http://us4.samba.org/samba/docs/man/Samba-HOWTO-Collection/samba- pdc.html#id2530254
"New to Samba-3 is the ability to function fully as an MS Windows NT4- style domain controller, excluding the SAM replication components. However, please be aware that Samba-3 also supports the MS Windows 200x domain control protocols."
using LDAP and various replication possibilities, the implication of SAM on multiple Domain Controllers is possible, but not the reality.
Craig
Bryan J. Smith wrote:
On Tue, 2005-12-06 at 00:40 -0500, Ugo Bellavance wrote:
<snip>
The drives will be used one week over 2.
What are you doing about long-term retention? Off-site?
Probaly rsync over ssh to my home server.
Number of servers: 1 for the moment.
Then you can just use local UNIX accounts. No directory server necessary.
Ok.
The prod server will be in colo. Types of users: see above. Amount of users: ~ 10 for now, may grow up to 20 max within 24 months. Reason for SMB : file/print sharing. CVS details? What do you need to know exactly? We are using CVS over SSH, Eclipse with ssh keys being the client. The developpers work sometimes in the office, sometimes from home, connected to a vpn (the endpoint is a m0n0wall firewall). The developpers have a Xampp setup on their laptops and develop there, then test on the staging server, then put it in prod. The staging server is also the development MySQL server. I'd like to use OpenXchange to have a mail/calendar/etc solution that can work with current tools (outlook :().
I'm very partial to OpenGroupware.ORG (OGo). OGo has a long way to go to be "easily installable," but it's the most flexible and open and _rich_ backend with _server_ side scheduling I've ever seen.
<snipped part about ogo>
I tried installing Ogo. Really not easy. Correct me if I'm wrong, but there is barely no install doc for RHEL...
OpenGroupware.ORG (SKYRiX 4.1) architecture: http://www.opengroupware.org/en/devs/docs/OGoArchitecture.html
Thanks for the link.
I just realized that horde is available in extras. It seems to be supporting PDA/outlook syncs. What do you think about it?
The server is a dual Athlon MP 1800, 1 gB RAM, 3 ware 7006-LP card in RAID 1 with 80 gB PATA HDDs + 1(X2) 200 GB removable hard drive (this server is also a backup server for a few servers for now, but this will probably change. Please let me know if you need more details. Thanks for your input ;).
Yeah, if you're 1 server, don't worry about a directory service just yet. Just use local accounts to get up'n running for now, then look at a directory service later -- especially when you have more time.
Ok, fiew! :).
Don't read all the Kerberos/OpenLDAP info on ADS. It's not required to run a Samba domain to XP clients, if you only have Samba servers.
Ok, thanks
Ugo Bellavance ugob@camo-route.com wrote:
Probaly rsync over ssh to my home server.
How are you rotating such rsync backups? The last thing you want is an incomplete or corrupted rsync to take down your only copy.
I tried installing Ogo. Really not easy. Correct me if I'm wrong, but there is barely no install doc for RHEL...
OGo is a PITA to install, no debate there.
Ok, fiew! :). Ok, thanks
That's the great thing about UNIX servers, you can always install and configure what you need later if you don't need it now.
With Windows, it's re-install and re-plan.
Bryan J. Smith wrote:
Ugo Bellavance ugob@camo-route.com wrote:
Probaly rsync over ssh to my home server.
How are you rotating such rsync backups? The last thing you want is an incomplete or corrupted rsync to take down your only copy.
Yes, I keep 7 days and put that on tape as well.
I tried installing Ogo. Really not easy. Correct me if I'm wrong, but there is barely no install doc for RHEL...
OGo is a PITA to install, no debate there.
Any opinion about horde and outlook/pda sync ?
Ok, fiew! :). Ok, thanks
That's the great thing about UNIX servers, you can always install and configure what you need later if you don't need it now.
With Windows, it's re-install and re-plan.
:) Glad to see that you just found a reason for not going for a SMB win2k3...
Thanks!
Ugo Bellavance ugob@camo-route.com wrote:
Yes, I keep 7 days and put that on tape as well.
Not too terribly bad of a strategy.
Any opinion about horde and outlook/pda sync ?
Nope.
:) Glad to see that you just found a reason for not going for a SMB win2k3...
One of the reasons I adopted NsDS years ago was because I don't like to mix native Windows and UNIX servers. I like to segment.
Ugo Bellavance wrote:
Hi,
I need to set up a small server for a group of ~10 employees (allusing Windows 2000/XP, used to use a windows 2000/exchange setup). I have a linux server already running CentOS 4, so I'd like to do all I can with this. I thought about using Samba for file/print sharing and OpenXchange (commercial version) to have a nice collaborative/mail/calendar/etc server. Of course, it would probably be the dhcp and internal DNS server.
I started reading the Samba doc, but it is rather long. I plannedon using this server as a PDC so that it is not too different from using their former windows 2000 server. I'll be managing this server, which is currently a staging server for web development (php/mysql/cvs).
Anyone has a opinion on this, or better ideas? My backups will be based on utilities and mondorescue, kept on a internal (cold-swap drawer) hard-drive that I would take every week (2-drawers rotation).
Any recommendations welcome, will provide more details if needed.
TIA,
There's a well-written tutorial at http://www-128.ibm.com/developerworks/eserver/tutorials/samba/ -- not necessarily for the latest version of Samba, but thorough nonetheless.
On Mon, 2005-12-05 at 18:10 -0500, Ugo Bellavance wrote:
Hi,
I need to set up a small server for a group of ~10 employees (all using Windows 2000/XP, used to use a windows 2000/exchange setup). I have a linux server already running CentOS 4, so I'd like to do all I can with this. I thought about using Samba for file/print sharing and OpenXchange (commercial version) to have a nice collaborative/mail/calendar/etc server. Of course, it would probably be the dhcp and internal DNS server.
I started reading the Samba doc, but it is rather long. I planned on using this server as a PDC so that it is not too different from using their former windows 2000 server. I'll be managing this server, which is currently a staging server for web development (php/mysql/cvs).
Anyone has a opinion on this, or better ideas? My backups will be based on utilities and mondorescue, kept on a internal (cold-swap drawer) hard-drive that I would take every week (2-drawers rotation).
Any recommendations welcome, will provide more details if needed.
As far as samba goes, I would recommend that you set up Samba and LDAP using idealx smbldap-tools.
We have been using these for about 2 years in our company ... seems to work well.
http://www.majen.net/smbldap/Samba-LDAP_smbldap-installer-1_2.html
Lots of good info in the above link.
On Monday 05 December 2005 18:10, Ugo Bellavance wrote:
Hi,
I need to set up a small server for a group of ~10 employees (all using Windows 2000/XP, used to use a windows 2000/exchange setup). I have a linux server already running CentOS 4, so I'd like to do all I can with this. I thought about using Samba for file/print sharing and OpenXchange (commercial version) to have a nice collaborative/mail/calendar/etc server. Of course, it would probably be the dhcp and internal DNS server.
eh a good and constructive proyect!
I started reading the Samba doc, but it is rather long. I planned on using this server as a PDC so that it is not too different from using their former windows 2000 server. I'll be managing this server, which is currently a staging server for web development (php/mysql/cvs).
for a quick samba understanding i recomend to you to read Samba by Example. the pdf version come with the samba package in centos and you can read online html version in
http://www.samba.org/samba/docs/man/Samba-Guide/
when samba works like PDC, for your workstation appear like a NT PDC server. You can view in samba by example that u need to integrate LDAP in the project. For a easy administration and creation of the domain i recomend to u the smbldap-tools package. (you can search this one in dag or the more general rpmforge repository)
u plan to integrate the comercial OpenXchange server. In the news, actually u can buy a combo for OX comercial and RHEL4 for almost the same cost that OX alone.
http://www.open-xchange.com/EN/shop/bundles.html
now u plan tu use the server for samba and open xchange. i do this config for a intitution in my country (770 users). I advice to you that you will need to modify or the default ldap configuration for samba or open xchange, to make both ones work with the same configuration. Not difficult but not elegant.
if u are planning commercial version OX, my recomendation is that u change the samba ldap configuration, and use the ldap version that will come with open xchange, don't use the ldap provided by centos if u put your system in a centos box.
-
Ajay Sharma -
Barry L. Kline -
Black Hand -
Bryan J. Smith -
Craig White -
Feizhou -
Johnny Hughes -
Josh Kelley -
Karanbir Singh -
Les Mikesell -
Robert -
Ugo Bellavance -
Yiorgos Stamoulis