unixforum.org

Форум для пользователей UNIX-подобных систем
https://unixforum.org/

Ищется правда о nx-клиентских шарах. (etercifs, freenx)

https://unixforum.org/viewtopic.php?t=119270

Страница 1 из 1

Ищется правда о nx-клиентских шарах.

Добавлено: 01.11.2010 02:10
dimbor
Опосля того, как был введен в эксплуатацию freenx==rx с подключением клиентских принтеров по cifs, выползла очень неприятная заморочка с подключением клиентских-же дисковых шар.
Эти шары великолепно себя ведут - подключаются, multimount... etc, только если на сервере нет "локальных" смонтированных ресурсов. (Под локальным ресурсом понимается серверный cifs-ресурс, смонтированный на серверный каталог. Сие делается для возможности одновременной сетевой и терминальной работы приснопамятной 1с-ки.)
Как только локальный маунт появляется, получаю калейдоскоп ошибок etercifs с различными последствиями для системы кроме тех, которые нужны.
Пырхаюсь набегами уже достаточно долго. Была переоткрыта, закрыта, перепроверена бага 4875.
Пока после echo 3 > /proc/fs/cifs/cifsFYI вытанцовывается в логах
kernel: Status code returned 0xc00000cc NT_STATUS_BAD_NETWORK_NAME
kernel: CIFS VFS: cifs_mount failed w/return code = -6


Эту самую NT_STATUS_BAD_NETWORK_NAME встречал еще, когда по smbfs все работало - там решалось отключением для удаленных шар ресолвинга бродкастами. Здесь пока не знаю, модуль ядра - не кот чихнул.

Так вот, спросить то че хочу: Наступал ли кто еще на эти грабли?

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 01.11.2010 09:38
DjSpike
Мне не приходилось сталкиваться, я всегда 1с запускаю в терминале, поэтому etercifs не пользуюсь...

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 05.11.2010 23:32
dimbor
Так вот, далее. Про перетягивание каната №4875 уже упоминал. Конечно победил Этерсофт, как более многочисленный ;) И молчат вторую неделю по всем вопросам - достал я их, видимо. Пришлось лезть в etercifs 4.5.4, т.к. юзеры плакали, а совесть за них болела.
Покрутил я эту хреновину и выяснил по первости, чтобы там был нормальный дебаг, нужна мелочь - ядро, пересобранное с CONFIG_CIFS_DEBUG2. Щас прям! Советская малина врагу сказала нет! © И был сделан хулиганский патч для возможности выяснения:
cat cifs_dbg.patch

Код: Выделить всё

--- cifs_debug.h.orig    2010-10-14 19:45:40 +0400
+++ cifs_debug.h    2010-11-05 21:07:58 +0300
@@ -46,7 +46,7 @@

 /* information message: e.g., configuration, major event */
 extern int cifsFYI;
-#define cifsfyi(format,arg...) if (cifsFYI & CIFS_INFO) printk(KERN_DEBUG " " __FILE__ ": " format "\n" "" , ## arg)
+#define cifsfyi(format,arg...) if (cifsFYI & CIFS_INFO) printk(KERN_ERR " CIFS FYI: " format "\n" "" , ## arg)

 #define cFYI(button,prspec) if (button) cifsfyi prspec

Повторяю, это - инструмент, и на качество/направление/скорость полета байтов не влияет.

И вот etercifs начал раскрывать свои заветные тайны. Все оказалось довольно просто. В коде вычитал, что туннелированая шара при наличии локальной НЕ БУДЕТ СМОНТИРОВАНА НИ ПРИ КАКИХ УСЛОВИЯХ (блин, капс залип). И в обратном порядке тоже. По крайней мере под 25-ым ядром. По причине того, что etercifs дюжеть вумный.
При любом маунте он сначала ищет существующую tcp-сессиию по целевому ip-шнику (!), находит и начинает радостно туда ломиться, экономный такой. Игнорируется даже жестко-заданный целевой порт. Мдя, как багу закрыли, ума не приложу. Хотя мож оно под другими ядрами и жизнерадостней.
По идее там надо cifs_find_tcp_session() из connect.c переписывать на предмет сравнения сокет vs входящие адрес+порт. Но лень.
Посему первый тост - за локалхост!

cat multilocal.patch

Код: Выделить всё

--- connect.c.orig    2010-11-04 21:40:08 +0300
+++ connect.c    2010-11-05 21:15:31 +0300
@@ -1917,11 +1917,12 @@
         }
     }

-    if (address_type == AF_INET)
+    if (address_type == AF_INET) {
+        if ( strncmp(volume_info.UNCip, "127.0.0.1", 9) != 0 )
         existingCifsSes = cifs_find_tcp_session(&sin_server.sin_addr,
             NULL /* no ipv6 addr */,
             volume_info.username, &srvTcp);
-    else if (address_type == AF_INET6) {
+    } else if (address_type == AF_INET6) {
         cFYI(1, ("looking for ipv6 address"));
         existingCifsSes = cifs_find_tcp_session(NULL /* no ipv4 addr */,
             &sin_server6.sin6_addr,


В итоге все монтируется в разных комбинациях. Впервые за пару лет поимел чувство чистоты и защищенности от того, что базовый функционал nx заработал полностью. Ложное чувство конечно - грабли грядут! ;)

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 06.11.2010 22:02
prof
dimbor писал(а): ↑
05.11.2010 23:32
По идее там надо cifs_find_tcp_session() из connect.c переписывать на предмет сравнения сокет vs входящие адрес+порт. Но лень.
Забавно. Вот код из 34 ядра, из той самой cifs_find_tcp_session:

Код: Выделить всё

                switch (addr->ss_family) {
                case AF_INET:
                        if (addr4->sin_addr.s_addr ==
                            server->addr.sockAddr.sin_addr.s_addr) {
                                addr4->sin_port = htons(port);
                                /* user overrode default port? */
                                if (addr4->sin_port) {
                                        if (addr4->sin_port !=
                                            server->addr.sockAddr.sin_port)
                                                continue;
                                }
                                break;
                        } else
                                continue;
Т.е., вроде бы должно учитывать порт, и эта недоработка исправлена в текущих ядрах. Может попросить etersoft приложить свои патчи на более свежий код.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 07.11.2010 00:13
dimbor
prof писал(а): ↑
06.11.2010 22:02
Забавно. Вот код из 34 ядра, из той самой cifs_find_tcp_session

Ага, обхохочешься. Даже можно без кода, по одним заголовкам:
cifs_find_tcp_session(struct sockaddr_storage *addr, unsigned short int port)

vs
cifs_find_tcp_session(struct in_addr *target_ip_addr,
struct in6_addr *target_ip6_addr,
char *userName, struct TCP_Server_Info **psrvTcp)

Почувствуйте разницу. И надо же, второй раз я все таки наступил на те грабли, которые обошел раньше, когда туда лазил - тогда под каким-то ядром он пущаться не хотел. Просто перенес пару строк из более свежего тарбола, и все завелось.
Даже с кем-то официальным на эту тему переписывался (не помню и не нашел). Задал вопрос, почему бы вместо тучи тарболов не обдефайнить код под разные ядра. Получил ответ, дескать тогда код будет из одних дефайнов состоять. Что крайность.
Сейчас имеем другую - 17 (семнадцать!) разных этеркифсов по факту. Стадо ошибок вылазит, фиксятся они на новых ядрах, но покажите людей, которые свежие дистры на рабочих серверах используют. Традиционное садо-мазо будет попроще и помягче.

prof писал(а): ↑
06.11.2010 22:02
Может попросить etersoft приложить свои патчи на более свежий код.

Да выхода другого и нет. Можно еще позвать этого с бритвой - философа. Или нанять 17 китайцев для сопровождения.
Так что очень прошу. Не знаю, как попросить сильнее. Могу багу очередной раз открыть, чтобы ее очередной раз закрыли.

А на тему я рано поставил "решено" - наивный чукотский парень. Грабли не заставили себя долго ждать. Все монтируется, но если сессия с шарой аварийно отваливается, дохлый маунт остается висеть. А последующий его umount -f, вызывает при условиях, описанных мной в баге, тот-же ступор всего кифса до reboot -n -f.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 08.11.2010 16:15
baraka
dimbor писал(а): ↑
05.11.2010 23:32
Так вот, далее. Про перетягивание каната №4875 уже упоминал. Конечно победил Этерсофт, как более многочисленный ;) И молчат вторую неделю по всем вопросам - достал я их, видимо.

На данный момент проблема разработчиками найдена. Бага переоткрыта и идет решение.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 08.11.2010 16:37
dimbor
Угу. Разработчиками. Если по начальной проблеме поиск завершится копи-пастом вышеозначенной функции, то по двум последним строчкам моего предыдущего сообщения его действительно придется поискать.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 08.11.2010 23:50
dimbor
Ура! - 4.5.5, полет пока нормальный по всем статьям. Эксклюзивное габаритное спасибо Павлу Шиловскому.
Тему пока не закрываю из суеверных соображений.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 12.01.2011 01:39
neonman
продублирую сюда мессадж, может разрабы etercifs увидят

etercifs 4.5.9, ядро 2.6.36, монтируется автоматом, всё хорошо, вот только внутри шары каталог создать можно, файл отредактировать можно, а вот создать новый файл или скопировать туда существующий - никак, mc например ругается на Недопустимый аргумент, а touch test.file - нет такого файла

опции монтирования - SMB_MOUNT_OPTIONS="iocharset=utf8,file_mode=0660,dir_mode=0770"

в разрешениях полный доступ (полнее не бывает) как на шару, так и в правах нтфс, прикол в том, что если использовать стандартный ядерный cifs-модуль - то файлы создаются нормально, но при этом 1с например запущенный в wine - виснет при попытке зайти в шару

из под рута в консоли без nx - при попытке сделать touch - тот же самый ужос - нет такого файла или каталога

если попытаться посмотреть strace например при копировании любого файла в подключенный каталог (хоть рутом) то можно увидеть следующее:

Код: Выделить всё

stat64("/home/test2/MyShares/test/", {st_mode=S_IFDIR|0770, st_size=0, ...}) = 0
stat64("/etc/nxserver/node.conf.d/10-samba.conf", {st_mode=S_IFREG|0644, st_size=980, ...}) = 0
stat64("/home/test2/MyShares/test/10-samba.conf", 0xbff925e4) = -1 ENOENT (No such file or directory)
open("/etc/nxserver/node.conf.d/10-samba.conf", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=980, ...}) = 0
open("/home/test2/MyShares/test/10-samba.conf", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0644) = -1 EINVAL (Invalid argument)

а вот например стрейс для touch

Код: Выделить всё

open("MyShares/test/12345", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK|O_LARGEFILE, 0666) = -1 EINVAL (Invalid argument)

аналогичная ошибка

кудыть копать?

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 12.01.2011 01:48
dimbor
А модуль в сислог ничего не пишет? А если его попросить о многословии аналогичным хулиганским образом?
Будете открывать багу - ссылочку пожалуйста сюда киньте.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 12.01.2011 01:54
neonman
да вроде бы ругани никакой нет:

Jan 12 01:32:55 term-srv sudo: test2 : TTY=unknown ; PWD=/home/test2 ; USER=root ; COMMAND=/sbin/mount.cifs //SHUTTLE/test /home/test2/MyShares/test -o uid=test2,gid=users1c,username=Guest,ip=127.0.0.1,port=5003,iocharset=utf8,file_
mode=0770,dir_mode=0770,wine,nounix,noperm,nostrictsync

и дальше тишина

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 12.01.2011 02:06
dimbor
neonman писал(а): ↑
12.01.2011 01:54
Jan 12 01:32:55 term-srv sudo: test2 : TTY=unknown ; PWD=/home/test2 ; USER=root ; COMMAND=/sbin/mount.cifs //SHUTTLE/test /home/test2/MyShares/test -o uid=test2,gid=users1c,username=Guest,ip=127.0.0.1,port=5003,iocharset=utf8,file_
mode=0770,dir_mode=0770,wine,nounix,noperm,nostrictsync

Это еще может быть та ёпрст с гостем, которую я прошляпил за ненужностью, а baraka в новом rx поправил.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 12.01.2011 02:16
neonman
да нет, гостя я сам в настройках клиента указал с пустым паролем, сейчас вынес fscache из ядра, откатился на стандартный ядерный cifs - 1с вроде бы перестала виснуть при входе в шару, пробовал открывать файлы с шары в 1ске и сохранять туда отчеты - вроде работает, а вот как только пытаюсь заюзать etercifs - тут же и вылезает эта бага

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 12.01.2011 13:58
baraka
В Этерсофт создали багу и уже исправили, осталось дождаться когда пересоберут пакет.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 12.01.2011 18:27
neonman
ой спасибо за оперативность :drinks: ждемс пакетик :)

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 12.01.2011 19:35
neonman
проверил, работает, спасибо за фикс :) задачу можно закрывать

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 09.04.2011 06:19
dimbor
Если бы...
От использования nx-овых шар в конторе месяц назад пришлось отказаться. Причина - такая шара в филиале с успехом валит центральный офис заодно со всеми остальными филиалами.
Причем отслеживание деталей падения проблематично (уволить-то не уволят, но репутационный ущерб обеспечен).
Сначала подключается филиал, в логах проскакивает

Код: Выделить всё

Mar  9 12:01:43 decsrv kernel:  CIFS VFS: Error connecting to IPv4 socket. Aborting operation
Mar  9 12:01:43 decsrv kernel:  CIFS VFS: cifs_mount failed w/return code = -111

Здесь подключается но без шары, естественно. Затем он еще пару раз отключается-подключается (suspend/restore) с нормальными логами freenx, но неизвестно, использует ли шару.

Далее филиал отключается, в логах freenx шару отключает с 14 (!) раза:

Код: Выделить всё

09.03 12:43:05: node_umount_smb (14041): Umounting "/home/nahim/Documents/Remote". Remain 30 attempts
09.03 12:43:12: node_umount_smb (14041): Umounting "/home/nahim/Documents/Remote" with '-f
...
09.03 12:43:47: node_umount_smb (14041): Umounting "/home/nahim/Documents/Remote". Remain 16 attempts
09.03 12:43:47: node_umount_smb (14041): Umounting "/home/nahim/Documents/Remote" with '-f'
09.03 12:43:48: node_umount_smb (14041): Mountpoint "/home/nahim/Documents/Remote" umounted


Пара suspend+restore, еще туда-сюда-обратно и:

Код: Выделить всё

09.03 18:18:36: node_umount_smb (19562): Umounting "/home/nahim/Documents/Remote". Remain 1 attempts

Шару отмонтировать не вышло, армагедец уже близко.

Следующим днем в локальной сетке с самбой начинают твориться чудеса.

Код: Выделить всё

Mar 10 15:27:34 decsrv smbd[24978]: [2011/03/10 15:27:34, 0] smbd/notify_inotify.c:inotify_handler(240)
Mar 10 15:27:34 decsrv smbd[24978]:   No data on inotify fd?!
Mar 10 15:27:35 decsrv smbd[24978]: [2011/03/10 15:27:34, 0] smbd/notify_inotify.c:inotify_handler(240)
Mar 10 15:27:35 decsrv smbd[24978]:   No data on inotify fd?!
Mar 10 15:27:35 decsrv smbd[24978]: [2011/03/10 15:27:34, 0] smbd/notify_inotify.c:inotify_handler(240)

Не читается и не пишется. Пингуется с секундными таймингами, кое-как по цепляется ssh, в top имеется отжирающий 100% вчерашний nxagent, но т.к. камней там четыре штуки, можно сделать вывод, что виноват охреневший IO.
В оконцовке вовремя не сделанный reboot -nf вынуждает к отправке менеджера по кнопку питания сервера.
На тестовом сервере воспроизвести не удалось - нужно где-то взять десяток smb-пользователей. Дальнейшие эксперименты на рабочем признаны вредными, т.к. роняется не только оный сервер, а еще и авторитет. Ему больно.

Осторожная попытка общения мылом с разработчиком этеркифса к результатам не привела (нэ ответил).
Багу заводить не стал - мутновато по логам. Даже если там все в едином порыве бросятся воспроизводить, вряд ли это выйдет.

Ех, и гиде ж ты, верный невъядренный smbmount?
Опять пичаль.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 10.04.2011 11:21
Djelf
dimbor писал(а): ↑
09.04.2011 06:19
От использования nx-овых шар в конторе месяц назад пришлось отказаться.

С обратной стороны тоже как-то не так получается. Но нашел такую штуку http://www.swish-sftp.org
Шикарно! Но нам без напильника, как всегда, обойтись не получится.
Думаю, надо nxservice пропатчить, чтобы где то, как то, он читал некий ini и добавлял проброс портов (localhost:ЧтоТоизИНИ>remote:22) в nxssh чтобы Swish заработал.
В принципе уже понятно куда курить, но формат ini и его расположение под вопросом.

Re: Ищется правда о nx-клиентских шарах.

Добавлено: 10.04.2011 22:32
dimbor
Идея конечно хорошая. Надо ее обкашлять. Создам ка я темку рядом.
У текущей схемы перспектив нет, хоть на ее развитие загублены лучшие годы жизни. Это ж надо было пингвинятникам додуматься, под проприетарную реализацию протокола (CIFS) в ядре подлизываться*. Да еще и smbmount слить в новых версиях самбы. Сервер реально колом встает от каждого чиха, как выньдовс какой-то.

Upd: *Поясняю, тут можно прочитать следующее:
В 1992 году появилась Samba — свободная реализация протокола SMB для UNIX-подобных операционных систем (изначально для SunOS). Поскольку Microsoft не опубликовала документацию значительной части своих дополнений к SMB, разработчикам Samba пришлось провести обратную разработку протокола.
...
В 2008 году, под давлением Еврокомиссии, Microsoft опубликовала описание своих проприетарных протоколов, в том числе и SMB, на сайте MSDN[6].

С одной стороны реверс-инжиниринг, с другой - если не изменяет память, были не раз ловлены на слабом соответствии своим же спецификациям. В итоге работоспособность cifs держится на тонкой ниточке допущений. Теперь добавить сюда "оплочные" исследования с приставкой eter-. То, что выходит, получается сырым. И место ему в userspace, а никак не в ядре. Такое вот оценочное суждение ©.
Часовой пояс: UTC+03:00
Страница 1 из 1