Имаме един ентусиаст в университета, който иска да прави студентски вестник. Първоначално идеята му беше да използва Joomla. Изглежда нещата не сработват както е очаквал и в четвъртък се появи с нова росна-прясна идея – wordpress. Качването на WordPress мина доста гладко и системата тръгна очаквано леко. Проблем се оказа качването на теми и приставки. За мое голямо съжаление в wordpress не видях инструменти за качване на такива благинки, което значи че админа на сървъра (т.е. моя милост) трябва да осигури достъп до файловата система. По някакъв начин.
Ето го и въпросът, чийто отговор търсих четвъртък и петък – как да разреша достъп на нашия ентусиаст до въпросните директории, но без да си докарам излишни главоболия? Решение от типа на cpanel е изключено по подразбиране – все пак не сме hosting provider. Първата реакция на всички около мен беше FTP. Но това би означавало още един демон, още един отворен порт, още логове… още главоболия. А и идеята за обяна на пароли по нешифрован канал леко притеснява моя шеф. Друг начин за който се сещам е да отовря достъп по ssh. Услугата и без това вече е налична на машината, макар и скрита зад port knocking. Но лично на мен тази идея ми се нрави още по-малко и от ftp-то.
В крайна сметка реших да използвам нещо, за която само бях чувал – WebDAV. Вярно, че ми трябваше само функционалността на ftp и изобщо не ми беше до distributed authoring & versioning, но пък опитът се очертаваше интересен. Намерих си прилично кратко и достатъчно ясно обяснение какво трябва да направя в gentoo-wiki и се заех да го приведа в действие. Е, наложи се да направя някои козметични промени по отношение на това кое къде се обявява в конфигурационните файлове, но то това си е закономерност. За известно време се опитвах да подкарам нещата с AuthType Digest, но при възникналите усложнения се задоволих и с Auth Type Basic и достъп през SSL режим.
Общо-взето в четвъртъчния следобед нещата работеха, до толкова до колкото можех с davfs да монтирам поделената директория от сървъра. Но и GNOMЕ и Windows категорично отказваха да се свържат със сървъра. Закономерно петъчния ден започна по същия начин. Почти съжалих, че се захванах с WebDAV, когато видях водопада от оплаквания от Web Folders функциите на Windows. Почти навсякъде имаше съвети за справяне с упоритоста на Джама. С изричното добавяне на порт към адреса или добавянето на знака ‘#’ в края на адреса успях да заобиколя глупостта на Windows-а да превръща адреса ‘https://server/share’ в ‘\\server\share’. Но въпреки това продължавах да не успявам да се свържа. Единствено успявах да пълня логовете с грешките, възникващи от опитите на служебния Джам да се свърже с ресурси като ‘_vti_inf.html’ и ‘_vti_bin’.
В петък най-накрая намерих в един относително забутан форум пост от човек, имащ същия проблем като мен. Напълно закономерно проблема ми се оказа тривиален – една наклонена черта. Windows се оказа много чувствителен към обявения път за контейнера в който е зададен ‘DAV On’. В моя случай, контейнера беше ‘<Location /wp-content/>’. Не си спомням защо съм сложил чертата зад името на директорията, но изтриването и позволи на Windows и GNOME да се свържат с ресурса.
В крайна сметка вече имаме отдалечен достъп до wp-content директорията на wordpress, всичко работи със средства налични във всяка съвременна ОС, не се е налагало да пипам защитната стена, да отварям портове и тям подобни гимнастики, дори не съм пускал допълнителни демони, а и шефа е доволен, че нещата минават по шифрован канал. Е, аз не съм съвсем доволен от пустия сертификат на сървъра, но това упражнение ще го проведа някой друг път 
