RE: [Samba] Support of Samba on RHEL4?
Hello Aaron, It is always good that people are thinking along and actually you ask right questions to me, which I asked myself too. To answer your questions: 1) No. 2) Yes 3) No, not yet. 4) They do that anyway ;) 5) YES! I have almost 100 Linux servers running with Red Hat Linux 9, you know, the obsolete version. ;) All these servers are running with Samba, which I tested and tested in our test environment against a real copy of our Active Directory. With RHL9 and Samba I have no support anyway and I'm on my own for support. Whenever a new update comes out I test it thoroughly in my test environment before I install it on all other servers. Before I roll-out an updated version of Samba I test it for a month on 1 or 2 production sites anyway. On my production servers I still run 3.0.14a of Samba, because that version works great against W2k3 server SP1. As soon as SP1 came out, samba.org immediately came up with a patch for Samba and this is the kind of support I need... Not how to install and configure it... ;) The only reason I stepped into RHEL4 was the hardware support. I have a new Dell PE2900 server with SAS drives and for RHL9 no drivers are available, so I had to step forward to RHEL4 (which is obvious for me). Maybe I have to consider CENTOS instead of RHEL4, because I didn't need RHEL4 for support from Red Hat, just for technical reasons. CENTOS4 is a 1:1 copy of RHEL4, but without the RedHat logo... (and the Red Hat support) Regards, Alex. -Original Message- From: Aaron Kincer [mailto:[EMAIL PROTECTED] Sent: Friday 15 September 2006 18:17 To: Alex de Vaal Cc: samba@lists.samba.org Subject: Re: [Samba] Support of Samba on RHEL4? Alex, I tried running Samba on RHEL4 Update 2 (on VMWare) and ran into some issues and I can provide you my opinion. Take care when making any decisions. There are quite a few things to consider: 1) Is having support from Red Hat on Samba necessary? 2) Are you confident enough in yourself to go off the beaten path from Red Hat? 3) Have you considered other vendors for support on Samba itself? 4) Would upper management (if any) hold you responsible for going off the support path in the event of an issue? 5) Do you have an adequate test environment? If you are going away from Red Hat support, #5 is critical. They test and test and test (or at least should) packages prior to pushing them out. They will know or be able to quickly find solutions to common problems with their packages. There are some caveats to that statement, so let me get to a bit more meat. Let's face it--the packages in RHEL4 for Samba are just plain old. Red Hat has back-ported security fixes and even some bug fixes, but I know without a doubt that not all bugs have been addressed. RHEL5 will be out in the coming future. Perhaps it will provide newer packages. I urge you to investigate and consider that route if you are extremely nervous about losing support on Samba from them. In my case, I've chosen to move my production File Server to Ubuntu 6.06 Server (well, I have loaded the latest distro upgrade) running Samba 3.0.22 after I complete quite a bit of testing. I just found myself banging my head against the wall with my smb.conf in ways that I shouldn't have to since the problems were with bugs in the older Samba that haven't been back-ported. The instant I transferred my smb.conf over to the new Ubuntu server, my bugs went away. The one exception is the archive bit issue I've been posting about lately. The bottom line in my humble opinion is that if you go your own way, you shift burden of responsibility more to yourself than Red Hat. Of course, if you have the hardware (or a VMWare/Xen virtual server) you could always run parallel using two servers with a Red Hat approved Samba version as a control and your own Samba server with identical configurations (minus Samba version) for production and work out non-bug related issues with their help on your reference server. This won't help you in resolving bug-related issues, but it could help provide you with a warm fuzzy-feeling. This would be less than ideal since the versions are so far apart. I know you asked for technical reasons, but you should be aware that not all of the factors in the equation are technical when considering a production server. Hope that helps. Aaron Kincer -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/listinfo/samba
Re: [Samba] Support of Samba on RHEL4?
Don't get me started on RH9 . . . Sounds like you have it under control, but I would fully recommend you check out Ubuntu 6.06 server. It doesn't load a GUI at all and is CLI by default. You could, if you really wanted, install one very quickly with apt-get (which compared to RPM is like an automobile to a horse and buggy). You can purchase support for Ubuntu if you need it. Red Hat has great support without a doubt (at least in my experience), but they do this often at the expense of using very old (but stable) packages. For many applications, this isn't too much of an issue since they are primarily in security fix mode with very few bugs and Red Hat back-ports the security fixes as necessary. As I understand it, Samba is a suite that is still in flux and therefore many bugs are being fixed rapidly. In light of this, I've been forced to decide that for the immediate future, Red Hat is not the most desirable choice of platform for Samba. I'm sure some would disagree and that's fine. I personally don't have time to be forced to spend hours on the phone with tech support or develop workarounds for bugs that are fixed in current stable versions of Samba. Good luck, Aaron Kincer Alex de Vaal wrote: Hello Aaron, It is always good that people are thinking along and actually you ask right questions to me, which I asked myself too. To answer your questions: 1) No. 2) Yes 3) No, not yet. 4) They do that anyway ;) 5) YES! I have almost 100 Linux servers running with Red Hat Linux 9, you know, the obsolete version. ;) All these servers are running with Samba, which I tested and tested in our test environment against a real copy of our Active Directory. With RHL9 and Samba I have no support anyway and I'm on my own for support. Whenever a new update comes out I test it thoroughly in my test environment before I install it on all other servers. Before I roll-out an updated version of Samba I test it for a month on 1 or 2 production sites anyway. On my production servers I still run 3.0.14a of Samba, because that version works great against W2k3 server SP1. As soon as SP1 came out, samba.org immediately came up with a patch for Samba and this is the kind of support I need... Not how to install and configure it... ;) The only reason I stepped into RHEL4 was the hardware support. I have a new Dell PE2900 server with SAS drives and for RHL9 no drivers are available, so I had to step forward to RHEL4 (which is obvious for me). Maybe I have to consider CENTOS instead of RHEL4, because I didn't need RHEL4 for support from Red Hat, just for technical reasons. CENTOS4 is a 1:1 copy of RHEL4, but without the RedHat logo... (and the Red Hat support) Regards, Alex. -Original Message- From: Aaron Kincer [mailto:[EMAIL PROTECTED] Sent: Friday 15 September 2006 18:17 To: Alex de Vaal Cc: samba@lists.samba.org Subject: Re: [Samba] Support of Samba on RHEL4? Alex, I tried running Samba on RHEL4 Update 2 (on VMWare) and ran into some issues and I can provide you my opinion. Take care when making any decisions. There are quite a few things to consider: 1) Is having support from Red Hat on Samba necessary? 2) Are you confident enough in yourself to go off the beaten path from Red Hat? 3) Have you considered other vendors for support on Samba itself? 4) Would upper management (if any) hold you responsible for going off the support path in the event of an issue? 5) Do you have an adequate test environment? If you are going away from Red Hat support, #5 is critical. They test and test and test (or at least should) packages prior to pushing them out. They will know or be able to quickly find solutions to common problems with their packages. There are some caveats to that statement, so let me get to a bit more meat. Let's face it--the packages in RHEL4 for Samba are just plain old. Red Hat has back-ported security fixes and even some bug fixes, but I know without a doubt that not all bugs have been addressed. RHEL5 will be out in the coming future. Perhaps it will provide newer packages. I urge you to investigate and consider that route if you are extremely nervous about losing support on Samba from them. In my case, I've chosen to move my production File Server to Ubuntu 6.06 Server (well, I have loaded the latest distro upgrade) running Samba 3.0.22 after I complete quite a bit of testing. I just found myself banging my head against the wall with my smb.conf in ways that I shouldn't have to since the problems were with bugs in the older Samba that haven't been back-ported. The instant I transferred my smb.conf over to the new Ubuntu server, my bugs went away. The one exception is the archive bit issue I've been posting about lately. The bottom line in my humble opinion is that if you go your own way, you shift burden of responsibility more to yourself than Red Hat. Of course, if you have the hardware (or a VMWare/Xen virtual server) you could always run parallel using two servers with a Red
Re: [Samba] Support of Samba on RHEL4?
Alex, I tried running Samba on RHEL4 Update 2 (on VMWare) and ran into some issues and I can provide you my opinion. Take care when making any decisions. There are quite a few things to consider: 1) Is having support from Red Hat on Samba necessary? 2) Are you confident enough in yourself to go off the beaten path from Red Hat? 3) Have you considered other vendors for support on Samba itself? 4) Would upper management (if any) hold you responsible for going off the support path in the event of an issue? 5) Do you have an adequate test environment? If you are going away from Red Hat support, #5 is critical. They test and test and test (or at least should) packages prior to pushing them out. They will know or be able to quickly find solutions to common problems with their packages. There are some caveats to that statement, so let me get to a bit more meat. Let's face it--the packages in RHEL4 for Samba are just plain old. Red Hat has back-ported security fixes and even some bug fixes, but I know without a doubt that not all bugs have been addressed. RHEL5 will be out in the coming future. Perhaps it will provide newer packages. I urge you to investigate and consider that route if you are extremely nervous about losing support on Samba from them. In my case, I've chosen to move my production File Server to Ubuntu 6.06 Server (well, I have loaded the latest distro upgrade) running Samba 3.0.22 after I complete quite a bit of testing. I just found myself banging my head against the wall with my smb.conf in ways that I shouldn't have to since the problems were with bugs in the older Samba that haven't been back-ported. The instant I transferred my smb.conf over to the new Ubuntu server, my bugs went away. The one exception is the archive bit issue I've been posting about lately. The bottom line in my humble opinion is that if you go your own way, you shift burden of responsibility more to yourself than Red Hat. Of course, if you have the hardware (or a VMWare/Xen virtual server) you could always run parallel using two servers with a Red Hat approved Samba version as a control and your own Samba server with identical configurations (minus Samba version) for production and work out non-bug related issues with their help on your reference server. This won't help you in resolving bug-related issues, but it could help provide you with a warm fuzzy-feeling. This would be less than ideal since the versions are so far apart. I know you asked for technical reasons, but you should be aware that not all of the factors in the equation are technical when considering a production server. Hope that helps. Aaron Kincer Alex de Vaal wrote: Hello, A while ago I asked what kind of Samba packages I could use on RHEL4. If I use the packages from www.samba.org then I'd void the support agreement with Red Hat. (...) Downloading and investigating the latest Samba source package from RHN (samba-3.0.10-1.4E.9.src.rpm) told me that the Samba package of RHN is based on the native 3.0.10 Samba package of samba.org with some necessary patches (samba-3.0.10-winbindd_2k3sp1.patch, samba-3.0.10-ldap-failover-timeout-backport.patch are the most important ones for me), while even the patches come from samba.org In samba-3.0.10-ldap-failover-timeout-backport.patch I found this statement: + /* Setup alarm timeout Do we need both of these ? JRA. */ This is from Jeremy Allison of samba.org... Is there any technical reason NOT to use the packages of samba.org on RHEL4? Regarding the above info I'd like to use the original samba packages on RHEL4. If I only void support for Samba at Red Hat, so be it. I'm convinced I'm better off with Samba support at samba.org... Regards, Alex. -Original Message- From: Gerald (Jerry) Carter [mailto:[EMAIL PROTECTED] Sent: Wednesday 12 July 2006 13:22 To: Alex de Vaal Cc: samba@lists.samba.org Subject: Re: [Samba] Fedora packages or Enterprise packages of Samba on RHEL4? -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alex de Vaal wrote: Can somebody of the Samba team explain me the difference of Fedora packages or Enterprise packages (http://enterprisesamba.com/) of Samba on Red Hat Enterprise Linux 4? ... First I tried the RHEL4 packages from enterprisesamba.com, but these packages always ended up with the error message Segmentation fault while I used net ads join; If you need support for the SerNet packages, you will have to contact SerNet. Therefore I compiled the Fedora source package on RHEL4; this went well. ... I'd like to continue with the Fedora Samba package on my RHEL4 server, but I'd like to know why or why NOT to use it! (and why I have to use the packages of enterprisesamba.com) The Fedora specfile provided with Samba is compatible with RHEL4. I don't build RHEL4 packages only because IMO if you pay for support for RedHat, installing non-vendor supplied packages would void
