*solved*lost file sharing after upgrading to latest version today

[mamra]

lost file sharing after upgrading to latest version today morning.
on webadmin shows file sharing stopped. restarting shows restarted correctly but module is stopped
zentyal error log shows:
2013/11/12 08:34:41 WARN> LDB.pm:197 EBox::LDB::safeConnect - Could not connect to Samba LDB: connect: Connection refused, retrying. (1 attempts)
2013/11/12 08:34:51 WARN> LDB.pm:197 EBox::LDB::safeConnect - Could not connect to Samba LDB: connect: Connection refused, retrying. (100 attempts)
2013/11/12 08:35:01 WARN> LDB.pm:197 EBox::LDB::safeConnect - Could not connect to Samba LDB: connect: Connection refused, retrying. (200 attempts)
2013/11/12 08:35:11 WARN> LDB.pm:197 EBox::LDB::safeConnect - Could not connect to Samba LDB: connect: Connection refused, retrying. (300 attempts)
2013/11/12 08:35:11 DEBUG> LDB.pm:201 EBox::LDB::safeConnect - FATAL: Could not connect to samba LDAP server: connect: Connection refused at /usr/share/perl5/EBox/LDB.pm line 201
   EBox::LDB::safeConnect('EBox::LDB=HASH(0x5abcd60)') called at /usr/share/perl5/EBox/LDB.pm line 155
   EBox::LDB::connection('EBox::LDB=HASH(0x5abcd60)') called at /usr/share/perl5/EBox/LDAPBase.pm line 95
   EBox::LDAPBase::search('EBox::LDB=HASH(0x5abcd60)', 'HASH(0x5ac3d60)') called at /usr/share/perl5/EBox/LDB.pm line 272
   EBox::LDB::domainSID('EBox::LDB=HASH(0x5abcd60)') called at /usr/share/zentyal-samba/s4sync line 71

[jerry_maori]

same problem. File Sharing 3.2.9

[BrettonWoods]

Same here.

I don't think I should say no more!

I put it into production today lol.

I have to ask how do these updates get released. What is the conception of zentyal releases?

[mamra]

this fixes issue:

chmod 0600 /opt/samba4/private/tls/key.pem

[BrettonWoods]

I could kiss you!

I have to wait an hour before I press that button again.

I feel sorry for the Dev's as they are doing a great job. It just shines through whoever is pushing the team too hard is out of reality.
Its like the release and removal of 3.0 before 3.2 bedded in, just unnecessary errors that probably wouldn't happen with a better timescale.

This rule underlies the fact that open-source software tends to stay in beta for a long time, and not get even a 1.0 version number until the developers are very sure it will not hand out a lot of nasty surprises. In the closed-source world, Version 1.0 means ``Don't touch this if you're prudent.''; in the open-source world it reads something more like ``The developers are willing to bet their reputations on this.''

http://catb.org/esr/writings/homesteading/homesteading/ar01s13.html

Ownership Rights and Reputation Incentives

We are now in a position to pull together the previous analyses into a coherent account of hacker ownership customs. We understand the yield from homesteading the noosphere now; it is peer repute in the gift culture of hackers, with all the secondary gains and side effects that implies.

From this understanding, we can analyze the Lockean property customs of hackerdom as a means of maximizing reputation incentives; of ensuring that peer credit goes where it is due and does not go where it is not due.

The three taboos we observed above make perfect sense under this analysis. One's reputation can suffer unfairly if someone else misappropriates or mangles one's work; these taboos (and related customs) attempt to prevent this from happening. (Or, to put it more pragmatically, hackers generally refrain from forking or rogue-patching others' projects in order to be able to deny legitimacy to the same behavior practiced against themselves.)

Forking projects is bad because it exposes pre-fork contributors to a reputation risk they can only control by being active in both child projects simultaneously after the fork. (This would generally be too confusing or difficult to be practical.)

Distributing rogue patches (or, much worse, rogue binaries) exposes the owners to an unfair reputation risk. Even if the official code is perfect, the owners will catch flak from bugs in the patches (but see [RP]).

Surreptitiously filing someone's name off a project is, in cultural context, one of the ultimate crimes. Doing this steals the victim's gift to be presented as the thief's own.

Of course, forking a project or distributing rogue patches for it also directly attacks the reputation of the original developer's group. If I fork or rogue-patch your project, I am saying: "you made a wrong decision by failing to take the project where I am taking it"; and anyone who uses my forked variation is endorsing this challenge. But this in itself would be a fair challenge, albeit extreme; it's the sharpest end of peer review. It's therefore not sufficient in itself to account for the taboos, though it doubtless contributes force to them.

All three taboo behaviors inflict global harm on the open-source community as well as local harm on the victim(s). Implicitly they damage the entire community by decreasing each potential contributor's perceived likelihood that gift/productive behavior will be rewarded.

It's important to note that there are alternate candidate explanations for two of these three taboos.

First, hackers often explain their antipathy to forking projects by bemoaning the wasteful duplication of work it would imply as the child products evolve on more-or-less parallel courses into the future. They may also observe that forking tends to split the co-developer community, leaving both child projects with fewer brains to use than the parent.

A respondent has pointed out that it is unusual for more than one offspring of a fork to survive with significant `market share' into the long term. This strengthens the incentives for all parties to cooperate and avoid forking, because it's hard to know in advance who will be on the losing side and see a lot of their work either disappear entirely or languish in obscurity.

It has also been pointed out that the simple fact that forks are likely to produce contention and dispute is enough to motivate social pressure against them. Contention and dispute disrupt the teamwork that is necessary for each individual contributor to reach his or her goals.

Dislike of rogue patches is often explained by the objection that they can create compatibility problems between the daughter versions, complicate bug-tracking enormously, and inflict work on maintainers who have quite enough to do catching their own mistakes.

There is considerable truth to these explanations, and they certainly do their bit to reinforce the Lockean logic of ownership. But while intellectually attractive, they fail to explain why so much emotion and territoriality gets displayed on the infrequent occasions that the taboos get bent or broken—not just by the injured parties, but by bystanders and observers who often react quite harshly. Cold-blooded concerns about duplication of work and maintainance hassles simply do not sufficiently explain the observed behavior.

Then, too, there is the third taboo. It's hard to see how anything but the reputation-game analysis can explain this. The fact that this taboo is seldom analyzed much more deeply than ``It wouldn't be fair'' is revealing in its own way, as we shall see in the next section.

http://catb.org/esr/writings/homesteading/homesteading/ar01s09.html