Topic: Hardware for new server, Suggestions ?

[Damien Ryan]

Hi All,

After years of setting up e-smith on old machines, I have a client who wants
a brand new raid gateway/server for their office.

My plan is to use the following config:
motherboard   Gigabyte GA-8PE667 Ultra main board with
                      Promise IDE RAID 0, 1 function plus UDMA ATA 133 support
                      Integrated Intel® PRO/100 VE Network Connection
harddrive         2 X Western Digital 80G 7200RPM ATA-100
network card   CNET 10/100 Network Card
CPU               Intel Pentium 4 2.40G (533Mhz FSB)  

Any suggestions anyone has most welcome


Damien

[Tyler Conrad]

Ok, that is some nice hardware you have posted. Only a few minor suggestions.

1. Get an a7n8x deluxe motherboard for the dual 1000 lan ports and onboard serial raid (just use adaptors to run ide).

2. Try the Special Edition Western Digitals. they have an 8mb cache which allows for faster data transfer.

3. Nice Processor choice, if u want to use the asus mobo u'll need amd tho. I suggest 2500 Barton core.

4. How much memory are you planning on running inside?

[Herculito]

Hi Damien,

I would avoid the promise controller (installation issues, no build in support e-smith not even 5.6, performance issues) and look for a real raid solution for example 3Ware (build software RAID works fine too).

Grtz,

Herc

[Guck Puppy]

Just FYI, the A7N8X mobo does indeed have two LAN ports - one is 100 (the 3com) and the other is 1000 (the 'Nvidia').

Amen to the Raid card idea - I hear nothing but badness about the onboard mobo 'raid controllers' and Linux.

G

[Graeme Fleming]

Gotta client running 5.6 on an AMD1800, 256MB SDRAM system using RAID 0 with 2 * 40GB WD drives (JB 8MB cache models).  System purrs along nicely as fileserver.

On other useful point is that the WD JB drives still have 3 year warranty wheras every other IDE drive I know of is now 1 year warranty.

HTH

[Tom Keiser]

You guys need to seriously reconsider using Raid zero. If *either* drive glitches or fails, you lose all your data.  Raid 1 (mirroring) or better yet Raid 10 (striping + mirroring) is a much better choice for speed and reliability. If you just want capacity, use Raid 5 -- and 3ware makes a decent card for this for IDE drives, but a SCSI Raid 5 is still the best.

And, if you use the WD drives, be certain to get the "JB" drives, the others are pretty junky.

[Tom Carroll]

I have just recently purchased three 100gb WD hard drives.  I plan to upgrade to SME 5.6 in June.  I am very interested in setting these drives up in a raid.

Do I need a raid controller, or can I use software raid?

What are the difference between the IDE raid and software raid?

If an IDE raid card would be better to use, which card has been found to work best with SME 5.6?

Thanks!

Tom

[Damien Ryan]

Hi All,

Thanks for all your suggestions.
Tom and Tyler, I'll make sure I use the Western Digital 80G 7200RPM ATA-100 (8Mb buffer) harddrives instead, and make sure they are 'JB'.

Herc and Guck, thanks for mentioning the onboard raid issues,
I'll scale the hardware back the the Gigabyte GA-8GE667 that lacks the onboard
raid, so as to avoid confusion as to what raid is operating.

I didn't realise e-smith could do software/emulation? raid.
I'm tempted to go down that path as the machine does not need to be
high performance, and I love simplicity.
My hardware supplier only seems to supply Adaptec raid cards.
If I use a raid card it will probably be an Adaptec IDE Raid 1200A.

Tyler, I'd be looking at 512 meg DDR 333 (2700?) RAM.

Tom Carrol, I don't know enough to answer your questions, but the above posts imply you can do the raid all in software (out of the box in e-smith/smeserver ??
not sure??). I'd be guessing hardware solutions would be quicker though.

thanks all

[Shane]

Hi all,
Most of us should only be interested in RAID for the added redundancy offered with mirroring our drives. I am sure the end users won't notice the extra 1/10000000000000 of a second it takes to open their email. LOL
If you require blistering disk performance, then you could consider a Compaq Proliant, or similar, with a hot swap raid 5 array (SCSI of course).  I happen to have an older one of these with a pentium pro 200 processor and 256 of ram.
There are plenty of companys out there that offer proven hardware packages, take your pick...
With todays modern processors and gigabytes of ram, software raid should be fine as long as there is a "nice" way to manage/maintain the array.


Just my 2 cents

Shane

[Tom Keiser]

First, here's an inexpensive, reliable place to buy 3ware:

http://www.hypermicro.com/store/index.htm

The Adaptec 1200A is not supported by Adaptec for Linux.

Second, while there are some here who like software raid, I've been put off that by the screams for help and confusion in getting the array back to normal after a drive failure.  It's pretty much a no-brainer with hardware raid, but that's just my opinion.

T.

[Kevin Flanagan]

Software RAID is a terrible solution!  IDE RAID is tolerable for relatively low end solutions, if you want RAID for availability or performance you should get a "real" server, one that comes with SCSI RAID included, and go with that, it's a good bit more dough, but FAR more reliable, and with the right controller, faster than IDE RAID of a similar configuration in most cases.

[Tom Carroll]

Thanks Kevin.  That is what I was looking for.  I did find out that I will need an IDE RAID card since I have three 100gb Western Digital drives.  I do not know if they are the "JB" drives mentioned earlier, but they are the 7200rpm with the 8mb cache on them - I think.  I will have to check them out.

It looks like the 3ware 5xxx/6xxx series ATA RAID card is supported according to RedHat, but I did see somewhere here that someone plugged in the 7xxx card it it
worked under 5.6.  So, I guess I will go out and grab one of those to use.  That card will cost me more than my three drives put together!

Anyway, thanks for the heads up.

Tom

[Charlie Brady]

Kevin Flanagan wrote:

> it's a good bit more dough, but FAR more reliable,

Really? Do you have evidence to support that? Do you know of reliability problems with linux's software RAID implementation?

Charlie

[Ed Form]

Charlie Brady wrote:
>
> Kevin Flanagan wrote:
>
> > it's a good bit more dough, but FAR more reliable,
>
> Really? Do you have evidence to support that? Do you know of
> reliability problems with linux's software RAID implementation?

It's certainly quicker, and with the major slowdown that you guys have imposed on us with 5.6 update 3 that starts to look very attractive.

Ed Form

[Charlie Brady]

Ed Form wrote:

> It's certainly quicker, and with the major slowdown that you
> guys have imposed on us with 5.6 update 3 that starts to look
> very attractive.

Excuse me, Ed, nobody has *imposed* anything on you. If you choose to use software which we make available, fine, but nobody is making you use it.

As to the slowdown you have experienced, I don't understand why a security fix to samba would make any difference at all. Nevertheless, any information you can provide about problems with the system can only help us, you and other users. And if you do know of reliability problems with linux software RAID, please let us know details.

Regards

Charlie

[Michiel]

For what it's worth: I've got update 3 running on software RAID 1 without any discernible slowdown or other side effect. The CPU is happily churning at 2% load.

[Ed Form]

In article <30a2410517be4a02b7b55c3b7414e8bb.phorum-owner@e-smith.net>, charlieb@e-smith.com (Charlie Brady) wrote:

> This message was sent from: Experienced User Forum.
> http://forums.contribs.org/index.php?topic=17131.msg66515#msg66515
> ----------------------------------------------------------------
>
> Ed Form wrote:
>
> > It's certainly quicker, and with the major slowdown that you
> > guys have imposed on us with 5.6 update 3 that starts to look
> > very attractive.
>
> Excuse me, Ed, nobody has *imposed* anything on you. If you choose to
> use software which we make available, fine, but nobody is making you use it.

Point taken, and apart from one client system which I installed when I first discovered E-Smith 4.1.2 and the client will not allow me to change to an alternative OS, plus my internal test server, I don't.

> As to the slowdown you have experienced, I don't understand why a
> security fix to samba would make any difference at all.

Nor do I, but it is a fact. I gave details in a message a few days ago and saw some confirmatory messages from others, as well as one or two who saw no change.

> Nevertheless, any information you can provide about problems with
> the system can only help us, you and other users.

If you are involved with disk intensive file processing you may notice a distinct problem with Update 3. The example I supplied earlier is to do with graphics file conversions.

On my test server I routinely carry out work for our own document scanning bureau business. One of the processes involves reading multipage G4 tiff files from the server disk to a workstation [Windows XP Pro] and converting them to Scansoft Paperport *.max files using the file import procedure of PaperPort itself, before writing them back to the server in another directory. Each conversion run involves a selection of 12-15 files varying from 60KB to 6MB in size and perhaps totalling 12MB. As each file is processed the importer displays a thermometer bar progress meter.

On 5.5, 5.6b7 and 5.6 unsupported release, this proceedure will hesitate and run slowly for the first file or perhaps the first two, and then each conversion for the rest of the day will run at high speed, the thermometer bar moving smoothly at a speed proportional to the size of the file being processed.

On Update 3 the process runs very slowly, with each page of the multipage file taking 3 or 4 seconds and the workstation processor having time to write a thumbnail of the partially converted file to the screen. This wading-through-treacle pace will persist for three or four files and then the rapid progress mentioned above will start and the batch is completed quickly.

With earlier releases, as I said above, the next batch will begin running at full speed and this will continue for the rest of the session, but with update 3, and to some extent with update 2, the dog-slow condition returns at the beginning of each batch. The net effect is to add hours to the processing of a large tranche of files.

The other symptom of the problem is the appearance, since update 2, of events at the server which can be distinctly heard as bursts of intensive disk activity, and during which all workstations stop dead if they happen to be communicating with the server at the time. There seems to be a relationship between mail activity on the server and this problem.

Let me further add a note about permission and file property difficulties with SME.

Certain Windows programs can not have their files stored on SME servers, and possibly not on any kind of Samba based SMB provider. Critically for me with a number of clients in the accountancy business, these include all of the Sage professional accounting packages, particularly Sage Taxation Suite [the product formerly known as Apex Taxation] and Sage Accounts Production. In that first case, the software runs once installed with its data on an SME server, but, as of Version 6 released this month, it cannot be updated. In the second case, the product registration process does not persist beyond the day on which the registration is carried out and, before the product can be used the next day, it has to be registered all over again.

The final situation of which I am aware is that Microsoft Access databases *cannot* be successfuly stored on SME servers. At some point corruption will occur as I have seen, now, on several occasions. This isn't the end of the world, because the MySQL set up you provide does a more than adequate job of substituting. Sadly however, some of the Sage products are Access runtime programs and get into difficulties. One in particular is the Practice Management package which a lot of accountants use to bill their time.

These, and a number of concerns about the commercial model used by Mitel, are the reasons why I will not use SME in client installations at this time.

> And if you do know of reliability problems with linux software RAID, please let us
> know details.

I don't, except for one situation: if one of your disks goes down you will suffer down time putting it right. They also give about a 2% loss of speed relative to a single disk and don't compare for performance to a decent SCSI system.

Ed Form

[Ed Form]

For some reason the following words did not make there way into the post I just sent...

> These, and a number of concerns about the commercial model
> used by Mitel, are the reasons why I will not use SME in
> client installations at this time.

I would like to do so, but I cannot.

Ed Form

[Ed Form]

Michiel wrote:
>
> For what it's worth: I've got update 3 running on software
> RAID 1 without any discernible slowdown or other side effect.
> The CPU is happily churning at 2% load.

I also do not see high processor loads, but disk performance is distinctly reduced.

Ed Form

[Kelvin]

I'm wading in on the RAID discussion here, mostly with grounds that have been covered before in previous posts.

Tom :
> The Adaptec 1200A is not supported by Adaptec for Linux.

Does not matter. The 1200A is based on a Highpoint HPT370A and the drivers from Highpoint's web site work just fine (and is supported out of the box with 5.6, I believe).

The 1200A does NOT support hot swap, though.

The Highpoint 404 does but is a more expensive card, as does the ACARD AEC-6885 (but have not worked with it on Linux though).

And, hotswap or not, they are easier to replace and bring back to operating status than S/W RAID. For one thing, I don't need to know any commands to do it, just follow the menu driven controller BIOS screens and we're up and running again.

For that matter, Adaptec will not even support the 2400A if your are not using the stock kernel that comes from the *STANDARD* download version of RH. Charlie Brady keeps insisting that SME kernels are standard, but from a hardware suppliers point of view, it is most certainly NOT. It matters little if RH recommends that you use kernel x,y or z. As long as it is NOT the kernel that ships with the normal downloadable ISO of RH, it is NOT supported by most hardware manufacturers.

Ed :
>The final situation of which I am aware is that Microsoft Access databases
>*cannot* be successfuly stored on SME servers.

I have a client whose entire inhouse system is a multiuser Access database application stored on an SME server and have been running it on SME 5.1.2 for more than a year and recently upgraded to 5.6U2 and continues to run it without encountering any database corruption so far (touching the biggest block of wood I can find !).

Kevin :
> but FAR more reliable

SCSI drives in in Compaq Server RAIDs die too (have clients using them). No more and no less than the many IDE RAID systems I have put in all over. IDE replacements are by far easier to come by.

If you want speed over simple redundancy, consider RAID 0+1 (more drives required but can still cost less than a SCSI based RAID !).

Kelvin

[Charlie Brady]

Kelvin wrote:

> For that matter, Adaptec will not even support the 2400A if
> your are not using the stock kernel that comes from the
> *STANDARD* download version of RH. Charlie Brady keeps
> insisting that SME kernels are standard, but from a hardware
> suppliers point of view, it is most certainly NOT. It matters
> little if RH recommends that you use kernel x,y or z. As long
> as it is NOT the kernel that ships with the normal
> downloadable ISO of RH, it is NOT supported by most hardware
> manufacturers.

No, not most hardware manufacturers. Only those manufacturers who 1) don't open source their drivers and 2) don't update their drivers when RedHat issues an updated kernel (for instance, for a critical security issue). They sound like manufacturers to avoid.

Charlie

[Kelvin]

Hi Charlie,

> They sound like manufacturers to avoid.

Oh rubbish !

3COM releases linux drivers but don't support any of them (even those on standard kernels). And they are not alone. I'm sure lots of e-smithers out there use Adaptec stuff too. You are basically saying to all of us, stuff these products because the manufacturers don't support Linux properly.

Hell, we might well say the same for QMail as well. As long as it is not the stock QMail, it is not supported. So should we avoid QMail as well ??

Kelvin

[Tom Keiser]

Charlie wrote:

> No, not most hardware manufacturers. Only those manufacturers who >1) don't open source their drivers and 2) don't update their drivers >when RedHat issues an updated kernel (for instance, for a critical >security issue). They sound like manufacturers to avoid.

This is certainly true and correct, but misses the point, IMO. For those who provide source code, the driver still must be compiled. This should be an easy task, but sometimes drivers provided by those on this forum simply don't work. Charlie, I believe your driver for the Adaptec 2400A is an example. I have never heard anyone say it works, but lots of folks say it doesn't. You yourself said you had no way to test it.

As for updated kernels, I can honestly say I have never seen a vendor who provides binary drivers for any device also provide them for any but the original kernel. Such vendors *MUST* be avoided, if you want to use a kernel that fixes the security issues, but for some reason, there is no unanimity on what updated kernel level should be used. This is a problem for RedHat to fix -- one mainly caused by rushing a new version to market every six months. Its a shame that the good code can't be backported into the offending kernel.

Tom

[Charlie Brady]

Tom Keiser wrote:

> For those who provide source code, the driver still must
> be compiled. This should be an easy task, but sometimes
> drivers provided by those on this forum simply don't work.

This then is an argument for using only hardware that RedHat and/or Mitel support out of the box, or hardware for which you yourself can build working drivers.

Charlie

[Charlie Brady]

Kelvin wrote:

> > They sound like manufacturers to avoid.
>
> Oh rubbish !

You're a very argumentative chap, Kelvin.
 
> 3COM releases linux drivers but don't support any of them
> (even those on standard kernels).

I was referring only to proprietary, closed-source drivers.  And wasn't talking of "support" in any case.

> Hell, we might well say the same for QMail as well. As long
> as it is not the stock QMail, it is not supported. So should
> we avoid QMail as well ??

Last I checked qmail was open source. And you can avoid qmail if you choose, but I wouldn't recommend that you do.

Charlie

[Charlie Brady]

Charlie Brady wrote:

> No, not most hardware manufacturers. Only those manufacturers
> who 1) don't open source their drivers and 2) don't update
> their drivers when RedHat issues an updated kernel (for
> instance, for a critical security issue). They sound like
> manufacturers to avoid.

Further to that, read this post:

https://listman.redhat.com/pipermail/ataraid-list/2002-August/001001.html

As I have reported previously, I'm running software RAID1 without any special drivers on a motherboard with Promise 20265 chipset. Just install using the non-Promise IDE connectors, then move the drives onto the Promise IDE connectors.

Regards

Charlie

[Kelvin]

Hi Charlie,

> You're a very argumentative chap, Kelvin.

On the contrary. If you follow most of my postings, you should have found that I take a fairly light hearted approach to the forums. What I will not stand for is people who are up themselves (eg. hardcore die hard Mac Users who refuse to see the shortcomings of their systems as well as Linux people who do not live in the real world -- figure that one out yourself !).

> Last I checked qmail was open source

Perhaps. But there is open source and there is open source. Yes, you can get the source and modify it to your hearts content. But yet, you are not allowed to distribute a modified qmail binary and still call it QMail. As far as DB is concerned, that could have changed QMail to a form that is no longer working as expected and so he will not allow the new version to be called QMail (even if you are allowed to use it). This IMO is no different from the stance hardware vendors take.

Tom wrote :
>This is a problem for RedHat to fix

Actually, I believe this is a problem for Linux to address. Linux must find a way to reduce / remove driver dependence on kernel sub-versioning. Let's take a silly example :- M$ issues many security hot fixes. If each of the hot fixes requires the users / admins to have to recompile all the various drivers before they can be reused, Redmond would have a revolt on their hands.

Kelvin

[Damien Ryan]

I hate to interrupt this lively debate, but I am looking for a practical
solution. Charlie, what is the solution for a raid 1 (ie data
reliability, no speed concerns) given a smallish budget.

Would you do
  software raid (I am impressed  it works out of the box on e-smith,
                      does it do the recovery just as easily ?)
  onboard motherboard raid (promise ?)
  Adaptec IDE Raid 1200A (cheap raid card)
  A more expensive IDE Raid card from 3Ware
  A scsi car and drives.

Damien

[Kelvin]

Hi Damien,

If you are not afraid of spending a little bit, take a look at something like the Accusys ACS-7500. It is a self-contained, OS independant RAID-1 chassis (just add your own drives) that also supports hot-swap with battery backup to track the automatic rebuild status. Being OS independant, it side steps the entire issue about driver support for a controller card, etc (as long as your on board IDE is supported, of course !).

If your client ever has the misfortune to suffer a single drive failure in one of these, you will be very thankful at the ease with which you can replace the faulty drive and not need any down time at all to do so.

Kelvin

[Greg Zartman]

Ed Form wrote:
> Let me further add a note about permission and file property
> difficulties with SME.

I thought I'd add my 2-cents here as I've run into various file issues stored on a Samba share over the years
 

> Certain Windows programs can not have their files stored on
> SME servers, and possibly not on any kind of Samba based SMB
> provider.

Ed, I highly recommend that you bring this to the Samba developers attention if you are truly having a problem.   The two driving concerns of the samba project is stability and transparency.  If after exhausting configuration options you still have a problem, let the developers know about it.   They are very responsive to things like this and will almost certainly fix the problem quickly if one exists.

 I don't have any experience with the Sage software that you mention in your post, but suspect that it uses some kind of a database.  The root of your problem may be with multi-user access of these datafiles.  I bet that a little tweaking of samba share configuration parameters were the data is stored will solve.  


> The final situation of which I am aware is that Microsoft
> Access databases *cannot* be successfuly stored on SME
> servers.

I think you are mistaken here Ed.  I have several access databases in excess of 200mb currently stored on my SME server.  Samba has never had a problem with storing database files (they are no different from any other binary file really), but it has had issues multi-user access of databases.    These issues were overcome with Samba configuration parameters targeted at oplocks.  I recommend that you search the samba mailing list archives for other experience: http://marc.theaimsgroup.com/

I'd also be happy to pass on my experience if you give me a little more info on that you are trying to do.

> These, and a number of concerns about the commercial model
> used by Mitel, are the reasons why I will not use SME in
> client installations at this time.

Why is that Ed?  If you pay for SME,  you certainly get what you pay for.  The same holds true if you don't pay.  I’ve played both fields with respect to which version of SME I run (i.e., pay vs free) and can honestly say that I got a better deal in paying for SME.  

When I first started using SME (just prior to the release of V5), it was the free version with several of Darrel May’s commercial contribs.  These commercial contribs were meant to simulate service link for the most part.  I paid ~$700 (ballpark) for these contribs and misc. support (Not all that much different from what one can now buy SME.).  For the most part these contribs worked great and the support was adequate (I’d be happy to comment more offlist).  Problem is, the developer of these contribs has pulled out of the mainstream SME community and has started his own mini-community.  What if he closes shop tomorrow?  Where would that leave the “mini-community” and those who rely on the third party contribs?  

Unless you are a wizard Linux/SME developer able to develop and/or fix third party add-ons, you are not wise to deploy SME for a clients.  If something goes wrong or a contrib becomes incompatible with the current SME, who are you going to call for help?

[Ed Form]

In article <6a3893284fb8085a11d713572fd2fe14.phorum-owner@e-smith.net>, greg@leiinc.com (Greg Zartman) wrote:

> This message was sent from: Experienced User Forum.
> http://forums.contribs.org/index.php?topic=17131.msg66530#msg66530
> ----------------------------------------------------------------
>
> Ed Form wrote:
>
> > Let me further add a note about permission and file property difficulties with SME.
>
> I thought I'd add my 2-cents here as I've run into various file issues
> stored on a Samba share over the years
>  
> > Certain Windows programs can not have their files stored on
> > SME servers, and possibly not on any kind of Samba based SMB provider.
>
> Ed, I highly recommend that you bring this to the Samba developers
> attention if you are truly having a problem.  The two driving concerns
> of the samba project is stability and transparency.  If after exhausting
> configuration options you still have a problem, let the developers know
> about it.   They are very responsive to things like this and will almost
> certainly fix the problem quickly if one exists.
>
>  I don't have any experience with the Sage software that you mention in
> your post, but suspect that it uses some kind of a database.  The root of
> your problem may be with multi-user access of these datafiles.  I bet that
> a little tweaking of samba share configuration parameters were the data
> is stored will solve.

I take your point about contacting the developers and will do so, but I think there is a general point here that needs to be addressed. In the real world, if Linux is to stand alongside Windows servers as a valid alternative, it needs to do a small number of things correctly. The first and most important is that it should present a  storage environment completely compatible with that normally presented by Windows. Needing to tweak parameters to reach that situation is crazy. A number of simple pieces of evidence show that it currently doesn't.

1. Multi-user use of access files stored in front-end/back-end form, with the data on a linux Samba server and the executables on Wndows 98 workstations gives rise to all sorts of trouble, up to and including loss of data. This is among the most obvious situations in which Samba needs to provide Windows-like behaviour as far as storage is concerned. Any simpleton can set up a test case because the situation is universally available and extremely commonly required. Why doesn't every Samba setup get this right?

2. Registration systems which depend on a combination of the creation date of a file, and the nature of its contents, fail on standard Samba setups because Windows does not read the creation date from the file but the last date on which the file was modified. This is the problem affecting the registration of Sage Accounts Production software that I mentioned in my last post . Why is the way in which Samba replies to date queries different from that of a typical Windows install? When this situation turned up the Sage helpdesk people put me in touch with a guy in Manchester who had the same problem and I don't believe he got it solved either. My clients just reregister the product every day!

Sage software themselves publicly deny that their software can be used on Linux servers, and they are very reluctant to offer support when Linux is in use. Since they are by far the biggest professional accounting software house in the world, and completely dominant in the UK, this is a bad situation.

The single client I have using SME likes the system so much that he has refused to allow me to remove it until now. This is in spite of two quite bad situations in the past, both of which I worked round. He lost his practice managment database during a routine upgrade on one occasion and I had to retrieve it from backup and update it using an external utility supplied by Apex Software themselves [They produced the software before Sage bought them]. No matter what I did it would not update using the routines on the product update CD without becoming hopelessly corrupt. The product is an Access Runtime application with a Borland Data Engine helper, and the data is stored in Access data files. Once passwords are known the tables can be inspected in Access. Nothing about it seems to be complex or unusual, but it doesn't update.

On the previous occasion when we had trouble, they crashed a workstation with an earlier version of the same program open and the data utilties that were supposed to mend the database actually ate it. We sent the files back to Apex on that occasion and they sorted them out.

3. A solution to the conflicts that occur betwen UNC and mapped drive disciplines when saving MS Office files on servers with a lot of documents stored [250,000 plus]. Again, these never occur on Windows servers; why do they happen on Samba servers after so many years of development?

My point here is that none of these things occurs on a Windows server even though the facilities it offers are notionally the same. This is only data storage, we're not running executables on the server. Unless Samba does just what Windows does when standard configuration parameters are used, something is adrift. The advice - adjust the settings - is fundamentally incorrect because it just prolongs a situation that shouldn't exist at all. Windows does these things as it comes; so should Samba, because Windows is the target.

> > The final situation of which I am aware is that Microsoft
> > Access databases *cannot* be successfuly stored on SME
> > servers.
>
> I think you are mistaken here Ed.  I have several access databases in
> excess of 200mb currently stored on my SME server.  Samba has
> never had a problem with storing database files (they are no different
> from any other binary file really), but it has had issues multi-user
> access of databases.  These issues were overcome with Samba
> configuration parameters targeted at oplocks.

No they weren't or the problem would not be occurring in the field on current versions of Samba. Knowing how to get round the problem is not a solution. The solution is making standard issue Samba on packaged Server OSs do it right out of the box!!!!!

Don't get me wrong here. I'm not hostile to Linux or Samba, and particularly not to SME which is so close to what is needed as to be well worth watching.

> > These, and a number of concerns about the commercial model
> > used by Mitel, are the reasons why I will not use SME in
> > client installations at this time.
>
> Why is that Ed?  If you pay for SME,  you certainly get what you pay
> for. The same holds true if you don't pay.  I’ve played both fields
> with respect to which version of SME I run (i.e., pay vs free) and can
> honestly say that I got a better deal in paying for SME.

The Mitel commercial packages make no sense at all in rural UK where the whole idea of online support is a bad joke and I have never been able to get any sense out of what was available anyway. Groupware was one item I saw when the Mitel site dealt with these matters, but php based groupware is pretty much worthless, and the economics of Linux-server based antivirus are not very good either. Again, with the UK telecoms market the way it is, having your own Web server has no great attractions yet the Web server aspect of SME is dominant and the products Windows compatibility has to be tweaked to get it right.

What is really required is a locked down file server OS with flawless Windows compatibility, a centralised Internet access facility for mail and browsing and a set of Java or Flash based groupware facilities that look nice on Windows workstations and allow completely transparent inter-colleague exchange - I've said this before here, but I'll trot it out again: what developers here should be doing is producing Windows applications to replace Exchange Server with something better.

> Unless you are a wizard Linux/SME developer able to develop and/or fix
> third party add-ons, you are not wise to deploy SME for a clients.  If
> something goes wrong or a contrib becomes incompatible with the
> current SME, who are you going to call for help?

Much the same can be said about any software product, but setting up a Linux Server with qmail, Squid, and Hylafax isn't exactly rocket science and doesn't put anyone into uncharted territory. Nor, if things go a little slewed are we likely to find that we have drifted up the proverbial creek without the required means of propulsion. Add carefully chosen applications that are stable on Samba storage and we're still sailing free - I use shared Lotus Organizer diary systems, and write my own MySQL tables with Web front ends for things like client lists - that's another thing. Why doesn't LDAP work on SME? Or, rather, why isn't it set up to work?

I could go on, but this isn't the place and I really don't want to come over as negative. I'm here to see what develops because, at the moment, it's really the only game in town that looks at all like it might get to be fun.

Ed Form

[Kelvin]

Hi Ed,

> Needing to tweak parameters to reach that situation is crazy.

I agree, but let's not stop at Samba. I would go as far as to say any sort of "tweaking" that needs to access the command line / config files to accomplish is also not ideal. Sure, you can draw parallels with modifying the Windows Registry, etc. But as you say, to accomplish "common" things out of the box, you should not need to tweak quite so many things. The template and server manager interface goes away towards simplyfying things, but I would say it over-simplyfies too many things and effectively, hides away a lot of the power behind a lot of the packages running on SME.

>Multi-user use of access files stored in front-end/back-end form, with the data on
>a linux Samba server and the executables on Wndows 98 workstations gives
>rise to all sorts of trouble, up to and including loss of data.

As mentioned in my previous post, I have a client using SME for their access database, exactly as you described but so far have not had any problems (thank goodness !). None the less, a strict backup regiment is maintained.

>Sage software themselves publicly deny that their software can be used on Linux
>servers, and they are very reluctant to offer support when Linux is in use.

They are not alone. I have come across very, very few companies that will actually commit to saying that their software will run off a Samba server and even those that do will absolutely NOT support it. This does not end with Software companies. A lot of ISPs are the same. If you run Windows, fine, their tech support will help you. If you are not, their general reply would be "There's no known problem at our end. The problem must be at yours. Unfortunately, we can only help you if you are running Windows (or sometimes Mac as well)".


>My point here is that none of these things occurs on a Windows server even
>though the facilities it offers are notionally the same.

Hmm.. I wonder what the situation is like with NAS devices and Appliance servers (like the Cobalt) which runs on a Linux core.


>Unless Samba does just what Windows does when standard configuration
>parameters are used, something is adrift. The advice - adjust the settings - is
>fundamentally incorrect because it just prolongs a situation that shouldn't exist
>at all. Windows does these things as it comes; so should Samba, because
>Windows is the target.

Agreed. As I said in previous posts, this is the real world situation. Unless the majority of the world runs Linux or some other OS with different set of file rules, etc., one must work with a Windows-centric mind set. As such, in the "real world", people will expect that if you put in place a server, especially one that is not M$ based, it must provide the same facilities (aside from running executables on the server itself -- even then I have a lot of clients asking to know why they can't -- again, this is the real world, not every client / user knows about OSes, different platforms, etc.). This also applies to device drivers, etc. If Linux users takes the stance that vendors who don't support or provide Linux drivers should be avoided, the real world situation would be most clients would say then that LINUX should be avoided, not the other way around.


Kelvin

[Greg Zartman]

> Windows. Needing to tweak parameters to reach that situation
> is crazy. A number of simple pieces of evidence show that it
> currently doesn't.

Mitel is 99% there with their standard template fragements.  SME is pretty good at serving a Windows network right out of the box, but nothing's perfect.  If you find a valid tweak that makes the system run better, let Mitel know about it.  They'll likely update the standard templates.

I will say that the ability to tweak is apositive, not a negative.  Windows is far to black boxed.

> commonly required. Why doesn't every Samba setup get this
> right?

I think for the most part Samba does get it right, provided the setup is correct.  If Mitel's implementation of Samba was fouled to any great extent, I think we'd be seeing more people belly aching about it on the boards -- which isn't happening.

> 2. Registration systems which depend on a combination of the
> creation date of a file, and the nature of its contents, fail
> on standard Samba setups because Windows does not read the
> creation date from the file but the last date on which the
> file was modified. This is the problem affecting the

I need to chew on this one a bit.

> 3. A solution to the conflicts that occur betwen UNC and
> mapped drive disciplines when saving MS Office files on
> servers with a lot of documents stored [250,000 plus]. Again,
> these never occur on Windows servers; why do they happen on
> Samba servers after so many years of development?

I don't want to open the windows/*nix advocacy "can of worms" as we could go on for weeks with the positives and negatives of both OSs.  Bottom line is you wouldn't be here it you didn't like SME to some extent.

> My point here is that none of these things occurs on a
> Windows server even though the facilities it offers are
> notionally the same.

Yes, but for every negative that you could come up with for a SME server, I could come up with a  matching negative for a windows setup...  I've been there and done that both here in my small office setup and working with a large e-commerce company that implemented a fleet of Windows servers.  

> running executables on the server. Unless Samba does just
> what Windows does when standard configuration parameters are
> used, something is adrift. The advice - adjust the settings -
> is fundamentally incorrect because it just prolongs a
> situation that shouldn't exist at all. Windows does these
> things as it comes; so should Samba, because Windows is the
> target.

Problem is, MS keeps changing the target.  There is no standard as far as MS is concerned.  They've introduced problems in service packs that foul up there own software as well as third party software.   Go have a look at the MS knowledge base and do a search for AutoCAD and Windows domain groups.  You will find that in order to get AutoCAD to run correctly on a window NT/2000/XP domain, you must run with it non-standard permissions.  That is, one must adjust the default windows settings to get the program to run correctly.  How is this any different from the advice I just gave you with respect to Samba?  MS nor the Samba development team can develop a solution that works in every situation.

> field on current versions of Samba. Knowing how to get round
> the problem is not a solution. The solution is making
> standard issue Samba on packaged Server OSs do it right out
> of the box!!!!!

That is impossible because there is no one solution.  See above.

> Much the same can be said about any software product, but
> setting up a Linux Server with qmail, Squid, and Hylafax
> isn't exactly rocket science and doesn't put anyone into
> uncharted territory.

Correct, but installing some of the contribs developed by this community can and does get people into big trouble -- if they don't know what they are doing.  Example:  Install the user-manager panel then plug in a receipt that looks for the subject "[Experienced User Form]", without escaping the brakets and see what happens to the email for the user account in question...    

>Nor, if things go a little slewed are we
> likely to find that we have drifted up the proverbial creek
> without the required means of propulsion.

For some reason your mail server quites working.  You reboot serveral times and nothing.  Who do you call for help?  

> I could go on, but this isn't the place and I really don't
> want to come over as negative.

No worries.  )

> I'm here to see what develops
> because, at the moment, it's really the only game in town
> that looks at all like it might get to be fun.

Like any *nix community: if you don't like something, jump in and help fix it.

Regards,

Greg Zartman

[Ron]

Back to the subject, I prefer rackmount solutions like:
http://www.giga-byte.com/Server/Products/Products_GS-SR113E.htm#
or
http://www.giga-byte.com/Server/Products/Products_GS-SR125.htm
Both are supported by RH 7.3