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
33 Replies
5260 Views