Comments 34
А можно посмотреть пример генерируемого отчёта?
Ну удали, ну узнали кто удали и что? Зачем этот костыль?
Может просто сделать файловое хранилище на базе NSS?
Зачем что то сочинять когда есть готовые промышленные решения!
Может просто сделать файловое хранилище на базе NSS?
Зачем что то сочинять когда есть готовые промышленные решения!
Были прецеденты, когда сотрудник нехорошо увольняется и пытается хлопнуть дверью. Восстановить из бэкапов — не проблема, проблемой было доказать, что удалил именно этот человек.
А что в этом контексте позволяет делать NSS?
Не знаете о salvage, то можно хотя бы почитать русскую вики Novell NSS
Поддерживается восстановление удаленных файлов ввиду отложенной «очистки» тома
Поддерживается восстановление удаленных файлов ввиду отложенной «очистки» тома
Уфф… <sarcasm>Неужели восстанавливать удаленное может только NSS?</sarcasm>
Повторюсь. Восстановление — не проблема. Бэкапы, теневое копирование есть, пользователи даже сами могут восстановить свои файлы из теневой копии.
Повторюсь. Восстановление — не проблема. Бэкапы, теневое копирование есть, пользователи даже сами могут восстановить свои файлы из теневой копии.
И — да, нетварь умерла, уймитесь уже.
Про salvage прочитал, не переубедился.
Про salvage прочитал, не переубедился.
Просто смешно читать про то что было сделано еще 15 лет назад.
Для понимания проблемы почитайте про мертвые файловые помойки под NW которые без обслуживания работали по 5 лет. И только после этого обсуждай что вы можете сделать под виндовозом и какими усилиям и что сделано под NW более 10 лет назад.
Для понимания проблемы почитайте про мертвые файловые помойки под NW которые без обслуживания работали по 5 лет. И только после этого обсуждай что вы можете сделать под виндовозом и какими усилиям и что сделано под NW более 10 лет назад.
15-20 лет назад нетварь это было круто, не спорю, и винде было далеко до нее. Во многом и сейчас далеко, но кого это волнует, кроме нескольких сотен некромантов?
Меня волнует на сколько эффективное решение используется.
Если окажется что эффективней купить 100 тыс. млн. рабов и они должны будут вести журнал и бакап на каменных табличках то они будут куплены. Но т.к 100 тыс. млн. рабов это не эффективно то мне такое решение не нужно. Даже решение на NSS не эффективно т.к не дает защиты от изменения данных в файлах.
Если окажется что эффективней купить 100 тыс. млн. рабов и они должны будут вести журнал и бакап на каменных табличках то они будут куплены. Но т.к 100 тыс. млн. рабов это не эффективно то мне такое решение не нужно. Даже решение на NSS не эффективно т.к не дает защиты от изменения данных в файлах.
А какой смысл вообще в файлере, на котором файлы защищены от изменения? Кстати, подобную защиту может дать Sharepoint, там есть версионность документов при каждом обновлении файла, с указанием, кто и что вписал в файл.
После того, как какой-либо сервер (хоть файлер, хоть астериск, хоть почтовик) простоит 5 лет без обслуживания, даже очень крутой специалист не сходу вспомнит, где какие педали, если нужно что-то существенно поменять. То, что кажется эффективным на этапе внедрения, нередко оборачивается головной болью впоследствии. Так не в одной компании было с Lotus Domino, например.
После того, как какой-либо сервер (хоть файлер, хоть астериск, хоть почтовик) простоит 5 лет без обслуживания, даже очень крутой специалист не сходу вспомнит, где какие педали, если нужно что-то существенно поменять. То, что кажется эффективным на этапе внедрения, нередко оборачивается головной болью впоследствии. Так не в одной компании было с Lotus Domino, например.
О да двайте еще один костыль прикрутим Sharepoint, раз файловая система г…
Еще в 1999 году в NW была функция делегирования управления каталогами, админу совершенно не надо было забивать себе голову всякой фигней.
И поверь
это не фотошоп, а доволно частое явление в NW.
Еще в 1999 году в NW была функция делегирования управления каталогами, админу совершенно не надо было забивать себе голову всякой фигней.
И поверь
это не фотошоп, а доволно частое явление в NW.Да кто бы сомневался, я сам такие скрины видел вживую, и на NW, и на никсах, и даже на винде (не 4,5 лет, но 3 года было). Счастье ведь не в этом. Опять же, файлер может быть включен, но недоступен. Постоянную доступность лучше обеспечить кластеризацией.
Делегировать управление я тоже могу, но, во-первых, это еще пользователей обучить надо (а они капризные), а во-вторых, случись что — люлей все равно получает ИТ-отдел, а не делегат.
Делегировать управление я тоже могу, но, во-первых, это еще пользователей обучить надо (а они капризные), а во-вторых, случись что — люлей все равно получает ИТ-отдел, а не делегат.
UFO just landed and posted this here
_del
.
А если злоумышленник откроет важный файл, удалит в нем все внутренности и сохранит пустой?
Или запишет туда всякую чепуху, а нужную инфу удалит.
Если была бы самба все это можно было бы отслеживать из коробки.
И удаление файлов, и запись файлов и т.д.
И ротация и защита логов, всё работает из коробки.
И никакие скрипты не нужны, всего несколько строк в конфиге.
Или запишет туда всякую чепуху, а нужную инфу удалит.
Если была бы самба все это можно было бы отслеживать из коробки.
И удаление файлов, и запись файлов и т.д.
И ротация и защита логов, всё работает из коробки.
И никакие скрипты не нужны, всего несколько строк в конфиге.
Это отслеживается все тем же аудитом. Из коробки, да. И запись, и перезапись. И ротация логов в винде есть. Генерируемые файлы — для того, чтобы не парить пользователей Event Log'ом.
И вот, хоть убейте, а использовать самбу (особенно третью) в лесу, где одних только доменов и поддоменов под сотню, а количество сайтов измеряется тысячами — это, как бы, по меньшей мере, не комильфо, как бы вам этого ни хотелось.
И вот, хоть убейте, а использовать самбу (особенно третью) в лесу, где одних только доменов и поддоменов под сотню, а количество сайтов измеряется тысячами — это, как бы, по меньшей мере, не комильфо, как бы вам этого ни хотелось.
Видимо, это вечная задача, сколько будут общие файлы, ровно столько раз она и будет решаться )
Помню, еще в школе году в 97-м, когда компы были маленькие, слабые и общие. Места всегда не хватало, поэтому кто больше всех хотел поиграть просто сносил нафиг файлы других пользователей. Времена были еще досовые, никаких логинов не было — выяснить кто и когда по системному журналу было нельзя.
Тогда пришлось написать резидентную програмку на ASM, которая вешалась на 21 прерывание, и логировала все попытки удаления файлов с указанием времени и имени файла в отдельный файлик в дебрях системы. После чего можно было легко понять, кто хулиганил.
Было очень интересно поработать с досом, одна ошибка — все повисло )
Помню, еще в школе году в 97-м, когда компы были маленькие, слабые и общие. Места всегда не хватало, поэтому кто больше всех хотел поиграть просто сносил нафиг файлы других пользователей. Времена были еще досовые, никаких логинов не было — выяснить кто и когда по системному журналу было нельзя.
Тогда пришлось написать резидентную програмку на ASM, которая вешалась на 21 прерывание, и логировала все попытки удаления файлов с указанием времени и имени файла в отдельный файлик в дебрях системы. После чего можно было легко понять, кто хулиганил.
Было очень интересно поработать с досом, одна ошибка — все повисло )
Отлично написано, спасибо. Случай поднять знания в PowerShell :).
Небольшая проблема — если выделить несколько файлов в папке и удалить — записывает только один, остальные из журнала не попадают в список.
// Добавлено // Оказалось, не запускались доп. экземпляры задачи — не отработало
Включил в задаче — всё отработало.
// Добавлено // Оказалось, не запускались доп. экземпляры задачи — не отработало
$taskDefinition.Settings.MultipleInstances = $TrueВключил в задаче — всё отработало.
Для корректной работы при удалении нескольких файлов — поправить код создания задачи:
иначе скрипт не успевает отрабатывать на всех удаляемых файлах.
Вообще — постоянное ведение журнала удаления файлов — спорное решение, скорее всего будет достаточно запроса к отслеживаемой папке при возникновении вопроса «Кто-кто-кто это сделал?...».
$taskDefinition.Settings.StartWhenAvailable = $True
$taskDefinition.Settings.MultipleInstances = 1иначе скрипт не успевает отрабатывать на всех удаляемых файлах.
Вообще — постоянное ведение журнала удаления файлов — спорное решение, скорее всего будет достаточно запроса к отслеживаемой папке при возникновении вопроса «Кто-кто-кто это сделал?...».
Ещё обнаружено — при удалении по сети регистрируется единственное событие 4659, которое тоже надо обрабатывать, причём отдельно — пока что сделал два файла и два журнала, осталось объединить, не получилось сразу.
Вообще — может, даже и лучше будет переписать это в виде формы с полями — период поиска, сервер, на котором надо искать, возможно, пользователя и маску имени файла — и запускать при необходимости, с выводом, например, в Out-Grid. Постоянный лог не так уж и нужен, большая часть его скорее всего никогда никому не понадобится.
Sign up to leave a comment.
Отслеживаем удаление файлов на PowerShell