Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 35
Хм, у нас наш 1Сник уже с полгода (если не с год) это использует, причем сам, без каких-либо пинков. Какие-то бестолковые у вас 1Сники.
Я своим 1С-никам с момента выхода 8.2 так сделал. Добавил пользователя в нужную группу — ему сразу влилась нужная платформа, и нужные конфиги.
Он у вас золотой. Мой опрос показал (хоть он и обширный), что 1С'ники ничего не знают про такую возможность. Более того, они не понимают смысл ключей в конфигурационных файлах. И когда у них 1С неадекватно ведёт себя у отдельных пользователей, то начинают что-то крутить у себя на сервере простым перебором.
В моем понимании это и есть работа админов, а не 1С-ников, хотя возможно сы просто разное понимание вкладываем в понятие 1С-ник.
В нашей схеме мы администрируем 1С сервер на самом верхнем уровне, и в 1С'ке на клиентах пользователей тоже: только, если в операционке косяки, скажем, службу грохнуть, или сервис какой запустить от нужного пользователя, то исправляем; если косяки в клиенте 1С'ки, или же на самом сервере 1С в его софтовой части, то мы туда даже не лазим. Т.е. администрированием 1С внутри неё занимаются 1С программисты сами, а точней начальник отдела их. И логи ошибок работы 1С клиента с сервером они сами мониторят и выясняют проблемы.
Может это не правильно, но у нас именно так, хотя мне такое разделение очень нравится.
Правда, порой, смотреть, как программисты администрируют, до слёз горько становится.
У нас в России изобилие софта, которое нормально только с правами Администратора работает. Вот уже смешно становится, когда очень несведущий бухгалтер работает на ноутбуке под администратором, потому что банк клиент иначе не работает, а ещё в целя безопасности они делают такой туннель, что компьютер от локалки отламывается.
Вот тут то и думаешь — Больше бы программисты администрированием знамались, чтобы не писать софтины, с которыми потом администратору приходится каждый день маяться и вспоминать бранным словом. Я про базовые понимания как работают операционные сети, разграничение прав доступа, владельцы и вся такая кухня.
Может это не правильно, но у нас именно так, хотя мне такое разделение очень нравится.
Правда, порой, смотреть, как программисты администрируют, до слёз горько становится.
У нас в России изобилие софта, которое нормально только с правами Администратора работает. Вот уже смешно становится, когда очень несведущий бухгалтер работает на ноутбуке под администратором, потому что банк клиент иначе не работает, а ещё в целя безопасности они делают такой туннель, что компьютер от локалки отламывается.
Вот тут то и думаешь — Больше бы программисты администрированием знамались, чтобы не писать софтины, с которыми потом администратору приходится каждый день маяться и вспоминать бранным словом. Я про базовые понимания как работают операционные сети, разграничение прав доступа, владельцы и вся такая кухня.
Это было первое, что я сделал. Сеть без домена, пришлось выкручиваться. Еще msi инсталлятор подправил, чтобы сразу нужный cfg файл кидался в папку.
Еще можно прикрутить это к группам в AD и добавлять непосредственно группы пользователю. Тут и при делегировании проще, сказал добавляй группу в AD без пояснений пойди туда найди файл, и статистику можно собрать.
Вот как это прикрутить к группам в AD, было бы интересно узнать.
А вообще идея такого именно поступка с конфигурационными файлами в шаре мне кажется более правильной, т.к. 1С разработчикам приходят запросы добавить базы пользователю, они же лучше знают, к какой базе, кому, как лучше цепляться. Они же лучше знают, какие базы не актуальны, и какие они перенесли на новый сервер. И лезть в эту кухню админам, это лишняя трата времени, совершенно лишнего человека в этой цепочки.
Конечно, если бы я администрировал их базы на серверах 1С и принимал по этому поводу решения, то вполне обосновано мне и заниматься базами. А так, получается интересная цепочка последовательности: Клиент — 1С разрабочик — Систеный администратор — Клиент — Системный администратор или 1С разработчик (в зависимости на кого позвонит клиент, если Админ не правильно понял 1С'ника — Согласование действий 1С'ника и Админа, что же сделать пользователю — Клиент (обычно во второй раз получает уже нужный результат и больше не звонит).
Или же:
Клиент — 1С разработчик — Клиент (проверяет результат) — 1С разработчик (если результат сразу не получился) — Клиент (на второй раз обычно получает правильный результат).
Это только касаемо конфигурационных файлов баз — не установка платформ. Во втором варианте полностью исключены вмешательства админов и права у 1С'ников при этом не повышались.
Нужно только первый раз подумать качественно будет конфигурационный файл строго для этого пользователя или для всего отдела, прописать на него ссылку пользователю (что делает админ), и всё дальше управление списками баз у 1С разработчиков.
Когда я взялся наводить порядок, я чуть с ума не сошёл, пока нашел повторяющиеся базы у пользователей, имеющие разные названия, и придумал сам как их назвать правильно и универсально, подходяще по смыслу.
А вообще идея такого именно поступка с конфигурационными файлами в шаре мне кажется более правильной, т.к. 1С разработчикам приходят запросы добавить базы пользователю, они же лучше знают, к какой базе, кому, как лучше цепляться. Они же лучше знают, какие базы не актуальны, и какие они перенесли на новый сервер. И лезть в эту кухню админам, это лишняя трата времени, совершенно лишнего человека в этой цепочки.
Конечно, если бы я администрировал их базы на серверах 1С и принимал по этому поводу решения, то вполне обосновано мне и заниматься базами. А так, получается интересная цепочка последовательности: Клиент — 1С разрабочик — Систеный администратор — Клиент — Системный администратор или 1С разработчик (в зависимости на кого позвонит клиент, если Админ не правильно понял 1С'ника — Согласование действий 1С'ника и Админа, что же сделать пользователю — Клиент (обычно во второй раз получает уже нужный результат и больше не звонит).
Или же:
Клиент — 1С разработчик — Клиент (проверяет результат) — 1С разработчик (если результат сразу не получился) — Клиент (на второй раз обычно получает правильный результат).
Это только касаемо конфигурационных файлов баз — не установка платформ. Во втором варианте полностью исключены вмешательства админов и права у 1С'ников при этом не повышались.
Нужно только первый раз подумать качественно будет конфигурационный файл строго для этого пользователя или для всего отдела, прописать на него ссылку пользователю (что делает админ), и всё дальше управление списками баз у 1С разработчиков.
Когда я взялся наводить порядок, я чуть с ума не сошёл, пока нашел повторяющиеся базы у пользователей, имеющие разные названия, и придумал сам как их назвать правильно и универсально, подходяще по смыслу.
Так как я являюсь тем самым 1с-ником, я участвовал только разборе файлов со списками баз и поиском решений, скрипт для AD по понятным причинам писать не допустили.
Наша схема выглядит иначе
Пользователь-диспетчер
После чего оформляется заявка
1с специалист добавляет пользователя непосредственно в нужную базу, в АD добавляют админы.
Схема пока внедряется, не без ошибок, но процесс явно идет на пользу.
Наша схема выглядит иначе
Пользователь-диспетчер
После чего оформляется заявка
1с специалист добавляет пользователя непосредственно в нужную базу, в АD добавляют админы.
Схема пока внедряется, не без ошибок, но процесс явно идет на пользу.
Только сейчас увидел статью, сам подобное прошел год назад :) Посколько поздно — лучше, чем никогда, у себя к GPO прикрутил это через настройку файлов (для 8.2) и реестра (7.7). В объекте GPO лежит тут: Конфиг пользователя / Настройка / Конфигурация Windows / Файлы
Самый сок состоит в том, что группы, к которым применяются соответствующие объекты, одновременно участвуют в ACL, т.е., все видят только то, что им положено.
Самый сок состоит в том, что группы, к которым применяются соответствующие объекты, одновременно участвуют в ACL, т.е., все видят только то, что им положено.
А у нас терминалы, разложил быстренько по папочкам и всё как надо, работы на 3 минуты
Давно 1Ску на GPO привязали и перекрестились. А так да решение из коробки не аховое, серверный/административный менеджер им бы не помешал.
В любой коробке (или это платформа к обучению или это типовая конфигурация) есть книжечка «Руководство администратора». Так вот она описывает структуру всех файлов и намекает как сделать вышеописанные танцы со списком баз. А вот еще помимо этого там описывается костыль (а иначе это не назовешь) как автоматически можно обновлять платформу на местах без использования домена. Как сотрудник 1С Франчайзи, стараюсь этой книжкой бить по лицу всячески акцентировать внимание на этой книжке местного 1Сника или сисадмина.
Это я к тому, что уважающий себя 1Сник должен это знать, а вот то, что написал автор статьи — очень хорошо для сисадмина. Автор не против если из этого будет сделана мануалка и будет использоваться в образовательных целях клиентов?
Это я к тому, что уважающий себя 1Сник должен это знать, а вот то, что написал автор статьи — очень хорошо для сисадмина. Автор не против если из этого будет сделана мануалка и будет использоваться в образовательных целях клиентов?
Буду только рад, если это пригодится кому-то. Я против копирастии, как бы это грубо не звучало.
Книжечку я не читал. Но читал стандартную справку, о чём написал в статье. Там всё очень кратко описано, что смысл не получается уловить. Сейчас, когда я суть всей этой кухни понял, то мне очень даже помогает вспомнить эта справка, но не в первый раз.
Книжечку я не читал. Но читал стандартную справку, о чём написал в статье. Там всё очень кратко описано, что смысл не получается уловить. Сейчас, когда я суть всей этой кухни понял, то мне очень даже помогает вспомнить эта справка, но не в первый раз.
Кстати к статье я ещё хотел приладить сообщения об идее распределённых конфигов, когда есть несколько серверов на удалённых площадках, тогда очень удобно делать шару для баз рядом с сервером на котором крутится база. В такой конфигурации соблюдается отказоустойчивость в плане, если потерялась связь с удалённым офисом, то потеряются только базы живущие там (т.е. не будут отображаться в списке), а у тех пользователей в их локалке они останутся присутствовать. Ну, это так быстро, но в принципе суть всей идеи охвачена. В статью я это не стал добавлять, т.к. переживал, что для освоения материала, может добавить сумбура. По крайней мере, когда своим 1С'кам про это стал рассказывать, они совсем потерялись. Тогда я понял, что лучше они базу схватят, а потом уже про распределённую сеть конфигов и отказоустойчивость им расскажу.
Я бы не стал так делать: если пользователь не увидит свою любимую «Бухгалтерию» в списке баз, то будет голова болеть сначала у 1Сника (хотя проблема на самом деле в связи с сервером). Таким образом получаем неправильный процесс решение вопроса. Если платформа не видит БД, то суть проблемы более ясна пользователю (в соответствующей ошибке), а значит и ее решение будет оптимальнее.
Из опыта: если существуют пользователи, которые работают на удалении от основной БД, то здесь на помощь приходят:
— терминальный сервер (рекомендовано)
— распределенная БД (несколько баз, которые периодически синхронизируются)
Из опыта: если существуют пользователи, которые работают на удалении от основной БД, то здесь на помощь приходят:
— терминальный сервер (рекомендовано)
— распределенная БД (несколько баз, которые периодически синхронизируются)
Идея этой концепции в том, что базы не будут доступны вместе с сервером 1С. От того, что база будет в списке сервер 1С не поднимется, если он лежит. А плюсом такой идеи является то, что рядом с сервером живёт список баз. Сервер перенесли, переименовали ещё что там можно сделать?.. Шару со списком баз не нужно тарнспортировать, переписывать конфигурационные файлы.
Суть идеи в том, чтобы конфигурационные файлы не вести в нескольких местах, а только в одном месте уникальном. Чтобы один раз поправил — у всех работает. Вы не забывайте, что есть пользователи А сервера А и есть пользователи Б сервера Б. А так же есть пользователи А сервера Б и пользователи Б сервера А. И вот в случае недоступности одного из серверов по причине отсутствия интернета, хотелось бы чтобы пользователи могли работать с доступными им серверами. И вот здесь как раз приходится всю эту распределёнку налаживать, чтобы была отказоустойчивость некоторая.
Когда возникает проблема с сетью, то не только 1С перестаёт работать, а соответственно и видиться списки баз, но и виндовые шары, почта… И в таких ситуациях начинают трепать первым делом первый уровень техподдержки, которые уже в курсе, что сети нет, что не будет работать то-то и то-то, и соответственно, не будут сношать мозги 1С разработчикам. А если и будут сношать, то у них вполне адекватный алгаритм решения начинающийся с проверки сети. Вообще всё в IT инфраструтуре начинается с проверки сети.
Воотще не понял как терминальный сервер и распределённая БД убирают проблему управления списками баз?.. Это риторический вопрос, проблема показывать списки баз ими управлять всегда останется. Если вы её отдадите на откуп ручному труду без оптимизации, то будете иметь достаточно немалую рутинную работу регулярно.
Я рассказал, как эту рутину бурать. С распределённой системой конфигурационных файлов там вообще рутины нет, кроме одного раза добавить пользователю права на нужный конфигурационный файл. или вписать в файл определённой группы другой конфигурационный файл. И всё. Дальше проблем не существует.
Суть идеи в том, чтобы конфигурационные файлы не вести в нескольких местах, а только в одном месте уникальном. Чтобы один раз поправил — у всех работает. Вы не забывайте, что есть пользователи А сервера А и есть пользователи Б сервера Б. А так же есть пользователи А сервера Б и пользователи Б сервера А. И вот в случае недоступности одного из серверов по причине отсутствия интернета, хотелось бы чтобы пользователи могли работать с доступными им серверами. И вот здесь как раз приходится всю эту распределёнку налаживать, чтобы была отказоустойчивость некоторая.
Когда возникает проблема с сетью, то не только 1С перестаёт работать, а соответственно и видиться списки баз, но и виндовые шары, почта… И в таких ситуациях начинают трепать первым делом первый уровень техподдержки, которые уже в курсе, что сети нет, что не будет работать то-то и то-то, и соответственно, не будут сношать мозги 1С разработчикам. А если и будут сношать, то у них вполне адекватный алгаритм решения начинающийся с проверки сети. Вообще всё в IT инфраструтуре начинается с проверки сети.
Воотще не понял как терминальный сервер и распределённая БД убирают проблему управления списками баз?.. Это риторический вопрос, проблема показывать списки баз ими управлять всегда останется. Если вы её отдадите на откуп ручному труду без оптимизации, то будете иметь достаточно немалую рутинную работу регулярно.
Я рассказал, как эту рутину бурать. С распределённой системой конфигурационных файлов там вообще рутины нет, кроме одного раза добавить пользователю права на нужный конфигурационный файл. или вписать в файл определённой группы другой конфигурационный файл. И всё. Дальше проблем не существует.
Вы 1С программист. Я угадал?!
Не получится написать конфигуратор с распределённой системой, т.к. не у всех может быть доступ, не везде может быть подход именно общий, могут быть нюансы.
Наличие конфигуратора не избавит вас от необходимости думать головой.
Но я могу попробовать, если мне заплатят деньги.
Не получится написать конфигуратор с распределённой системой, т.к. не у всех может быть доступ, не везде может быть подход именно общий, могут быть нюансы.
Наличие конфигуратора не избавит вас от необходимости думать головой.
Но я могу попробовать, если мне заплатят деньги.
до домена использовал logon-скрипт для формирования списка баз и закидывания в профиль. Юзер садился в группу, группа получала logon-скрипт.
После перехода в домен стал использовать folder redirection и ферму терминальных серверов. 1 раз создал базу — и «на века», а создавать можно прямо в хранилище профилей.
После перехода в домен стал использовать folder redirection и ферму терминальных серверов. 1 раз создал базу — и «на века», а создавать можно прямо в хранилище профилей.
Я честно сказать не понял зачем так сложно, ведь есть «список общих информационных баз». Запускаете ярлык 1с, нажимаете настройки, туда добавляете файл(ы) лежащие на каком-нить сетевом диске. Все.
У нас с 1С работает порядка 300-400 людей, большая часть из которых обладает компьютерной грамотностью на уровне детского сада.
Мы проходили этот вариант. И мануал с картинка рассылали и видео снимали, и все равно были вопросы у большой половины.
От сюда только один правильный вывод, чем меньше пользователь «настраивает» тем тебе спокойней.
Мы проходили этот вариант. И мануал с картинка рассылали и видео снимали, и все равно были вопросы у большой половины.
От сюда только один правильный вывод, чем меньше пользователь «настраивает» тем тебе спокойней.
Так это не их задача, я про то что добавьте каждому пользователю одни раз, при установке платформы например, ссылку на список общих информационных баз, а далее редактируйте его по необходимости, уже без их участия. Хоть каждому пользователю создавайте свой список (обычно конечно хватает общий список по ролям, либо выполняемым задачам: Менеджеры, Бухи, Итд.) Или я что-то не так понял?
Список общих баз подходит если баз мало и они у всех. У нас порядка 12+ только бухгалтерских и каждому пользователю из них нужна одна, две. В статье как раз и описывает как удаленно менять списки не используя общий.
Тут, я бы вас поправил используются всё те же общие списки баз, просто там система должна быть из нескольких их, и чтобы пользователь своими шалавливыми руками не смог это поломать, а вы могли не заходя на его компьютер. Я вношу эту ясность, чтобы у людей не закралась мысль, что это что-то другое. Механизмы задействуются те же, о которых говорит AndreyKu.
А можно так же сделать с программной лицензией? Ведь файлик *.lic тоже храниться в каком-то из этих каталогов.
В статье есть фраза «если вид представления списка баз выставлен деревом».
Каким образом можно заставить список баз отображаться у всех в виде дерева? В каком файле эта настройка хранится?
Каким образом можно заставить список баз отображаться у всех в виде дерева? В каком файле эта настройка хранится?
Нет этой настройки. Список баз представляется пользователю так, как он выберет:
Вы можете в конфигурационном файле указать каталог, в котором база будет лежать. Который также создастся и отрисуется в списке. Под словом каталог я понимаю сущность в списке баз, а не каталог в файловой системе, чтобы вы понимали.
При первом получении списка организуется всё так, как вы опишите в файле. Потом, человек волен перетащить базу в другой каталог у себя на компе, и его 1С на его компе запомнит это и будет ему показывать то, что он наваял. И с порядком баз в списке та же «петрушка». А вот поправить сами настройки базы, которые редактируются через этот список в такой удалённой базе он не сможет. В этом универсальность. Человека не закрепощают в той организации каталогов, которую ему прислали и он способен чуть это попреятней расположить, но получать в список базу удалённую он будет. Тока, если он ручкам не создаст идентичную по наименованию, тогда проблема.
- либо списком без иерархии
- либо деревом в иерархии папок
Вы можете в конфигурационном файле указать каталог, в котором база будет лежать. Который также создастся и отрисуется в списке. Под словом каталог я понимаю сущность в списке баз, а не каталог в файловой системе, чтобы вы понимали.
При первом получении списка организуется всё так, как вы опишите в файле. Потом, человек волен перетащить базу в другой каталог у себя на компе, и его 1С на его компе запомнит это и будет ему показывать то, что он наваял. И с порядком баз в списке та же «петрушка». А вот поправить сами настройки базы, которые редактируются через этот список в такой удалённой базе он не сможет. В этом универсальность. Человека не закрепощают в той организации каталогов, которую ему прислали и он способен чуть это попреятней расположить, но получать в список базу удалённую он будет. Тока, если он ручкам не создаст идентичную по наименованию, тогда проблема.
На самом деле вы неправы, настройка есть (речь про иерархию).
Файл называется %AppData%\1C\1cv8\1cv8strt.pfl, он во внутреннем формате 1с, в нем нужно поменять кусок
«ShowIBsAsTree»,
{«B»,0}
на
«ShowIBsAsTree»,
{«B»,1}
Файл называется %AppData%\1C\1cv8\1cv8strt.pfl, он во внутреннем формате 1с, в нем нужно поменять кусок
«ShowIBsAsTree»,
{«B»,0}
на
«ShowIBsAsTree»,
{«B»,1}
Я имел ввиду в рамках в рамках системы представления списков баз конфигурационными файлами .v8i и .cfg. А та настройка, о которой вы говорите не предполагает распределённо задавать эти данные. Это уже в профиле пользователя на конкретной системе.
Справедливости ради замечу, что не знал, где в файликах можно поправить, чтобы изменить вид представления списков.
Справедливости ради замечу, что не знал, где в файликах можно поправить, чтобы изменить вид представления списков.
.
раз уж я тут восстановил (временно)) пароль от хабра, то загляну и сюда
Воспользовался концепцией указанной @zurapa с существенной автоматизацией.
исходные данные - несколько бух компаний, 1с сервер, 450+ активных баз, около 1000 архивных баз, 50+ сотрудников +внешние подключения от клиентов в их базу, небольшая текучка, домен. юзер видит только свои базы, директор конторы все базы конторы.
1 на каждую базу создан файл списка баз и группа АД для этого списка с делением по каталогам/юнитам на активные и архивные
2 создан общий конфиг файл с перечислением адресов файлов списка баз, по одному для активных и архивных
3 создана политика распространяющая правильный конфиг файл на пк юзеров, включая терминальники (в котором указываются пути к основному и архивному конфиг файлу), а также правящая права на конфиг.длл, чтобы юзер не смог войти в конфигуратор.
4 написан скрипт на ПШ с ГУИ, который читает скл-базу с учетом 1с баз, к этому также прикручен ГУИ, а также читает инфу о юзерах из АД.
далее при заполнении полей (имя базы и/или юзер и/или директор) можно создать новую базу с добавлением прав на нее, добавить права, удалить права, архивировать базу по протоколу, деархивировать базу по протоколу, посмотреть текущую инфу о базе. потом после нажатия кнопки "старт" происходит магия и у юзера после релогина (увы, керберос все поганит), появляется/исчезает база в списке. остается только запустить обработку из отдельной управляющей учетной конфиги для всех баз, которая подключается в конфигу только что созданной базы, создает там юзера с нужными ролями и доменной авторизацией.
зашифровал переменные скрипта сертификатом и отдал в пользование эникеям.
время создания базы из шаблона сократилось примерно в 6-7 раз по сравнению с ручным вариантом, т.е. благодаря скрипту, притом что 95% времени эникей смотрит в прогрессбар)
до этого предыдущими админами использовался подход "у каждого юзера в его сетевом диске есть файл списка баз, который админ правит вручную, добавляя базу, а рядом батник, который заменял юзерский файл в профиле вот этим, юзер сам запускал этот батник". само собой никто не парился удалением баз.
все работает несколько лет без технических сбоев, косячат только люди)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Управление списками баз 1С 8.2