INFO
Problemet här är att även om det finns en fil-låsningsmekanism i CIFS, och Alfresco kan kontrollera det och upptäcka när det sker en filsparning och tillämpa versionering i bakgrunden, finns det inget sätt att kontrollera hur klienten implementerar en filsparning. Många dokumentredigeringsklienter implementerar någon form av temporär fil där den faktiska sparningen sker, tills du slutligen stänger dokumentet, originaldokumentet raderas av klienten och ersätts av den temporära filen som nu bytt namn till originalnamnet. Detta måste Alfresco upptäcka för att faktiskt göra versionering, och inte bara en enkel radering och skapande av ett nytt dokument. Min avsikt här är inte att exakt förklara processen, utan snarare ge dig en snabb inblick i vad Alfresco måste hantera. Och om du tror att Microsoft Office-sviten har ett sätt att göra en filsparning, tänk om. Inte bara skiljer sig filsparningsprocessen mellan de olika Office-produkterna, den skiljer sig också mellan versioner, Microsoft Word 2003 har en annan sparningsprocess än version 2007. I version 4 av Alfresco har detta äntligen hanterats på ett tillförlitligt sätt, och jag känner mig bekväm med att säga till mina kunder att de kan använda cifs utan att filredigering i vissa fall förstör filerna.
Så för en av mina kunder uppgraderade vi snabbt till version 4 och implementerade Alfresco med Share-klienten som inte bara fungerar som ett samarbetsverktyg utan också som deras intranät. Och med dokumentredigering via cifs med Single Sign On med Kerberos. Och till att börja med fungerar allt bra. Tills de börjar med en större utrullning för att låta fler användare redigera via cifs. Då får vissa användare åtkomst nekad och blir uppmanade att logga in, men inga inmatade uppgifter fungerar någonsin. Och dessa klienter är alla på en Windows 2008 Terminal Server. Och en felsökningsresa börjar som slutar i en mycket märklig lösning.
Rapporterna om detta fel började komma in den andra veckan i januari. Från slutanvändarnas perspektiv är det Alfresco som misslyckas, men när man undersöker problem som detta kan det vara nästan vad som helst från Windows OS, nätverksutrustning och Alfresco. Du måste bara hålla ett öppet sinne för alla möjligheter och inte börja ett skuldspel mellan Windows-, nätverks- och Alfresco-administratörer. Här är några av de saker vi försökte tillsammans (inte specifikt i denna ordning):
- Det fanns ett autentiseringsfel i Kerberos. Så i Alfresco aktivera all Kerberos- och autentiseringsloggning som finns. Men inga autentiseringsfel i loggen alls. Det fungerar antingen, eller inte.
- Windows-administratörer märker att detta händer runt 50 användare som är inloggade på Terminal Servern. Så kanske ett throttling-fel med Active Directory-servrar. En andra terminalserver implementeras, men på denna server händer det runt 10 användare?
- Verifiering av alla krb5.conf-inställningar, skapa nya keytab-filer och distribuera på Alfresco-servern.
- Uppgradering av Ubuntu-versionen på servern där Alfresco körs.
- Uppgradering av Alfresco-versionen till senaste Alfresco Community 4.0.d.
- Omstart av Terminal-servrar. Hjälpte tillfälligt, men cifs-sessioner började efter ett tag nekas igen.
- Paketspårning, stirra sig blind på paketspårningar. Vi kunde fånga autentisering nekad för SMB, men det fanns ingen ledtråd överhuvudtaget om varför.
Inget av ovanstående gav någon insikt, och vi försökte många fler saker som inte nämns här. Och om du har cirka 200 användare som är beroende av att Alfresco-servern är tillgänglig, kan du inte bara starta om Alfresco för att testa konfigurationsändringar, eller terminalservern. Det skulle förmodligen ha sparat lite tid om du använder Alfresco Enterprise, där du kan ändra konfiguration och loggnivåer utan omstart.
Vad som slutligen gav en ledtråd om vad som pågick var att sätta cifs.sessionDebug-flaggorna i alfresco-global.properties. Eftersom vi inte hade någon aning om var felet kunde vara, aktiverades nästan alla tillgängliga flaggor. Och det spottar ut massor av information, och där hittade vi:
[SMB] Failed to allocate UID for virtual circuit, [0:-1,
[peter@DOMAIN.NET:null,,,192.168.10.10,Normal],Tree=0,Searches=0]Och det verkar finnas några lösningar på SMB-sessionsläckorna, eftersom min kund har sin Terminal Server i fungerande skick har de inte testat dem. Men jag tycker att jag borde nämna dem, och om du har någon erfarenhet av dem låt mig veta.