Почему не делает inotifywatch, обнаруживают изменения на добавленных файлах?
prompt
mget ~/public_html
Это должно загрузить все с /home/username/public_html каталог.
Ну, я могу придумать два встречных пункта к идее отдельных счетов.
Во-первых, существует один большой недостаток с классическими группами Unix по сравнению с общим общим деревом файлов, и то есть каждый пользователь и каждый выполняемый им сценарий должны иметь umask, который сохраняет файлы и каталоги с возможностью записи в группу, и вы должны применить бит group-sticky ко всем каталогам. На практике это трудно, потому что так много скриптов указывают ограничительную umask, и потому что если вы rsync -a или cp -a или tar -x файлы из каталога вы владеете в общем дереве легко забыть добавить группу-липкий бит и изменить То, что вы в конечном итоге с поддерево файлов, принадлежащих Джо и Джо в отпуске или на обед, и кто-то должен изменить эти файлы, и вы должны пойти найти sysadmin, чтобы исправить его. IMHO дизайн разрешений Unix прост и эффективен, но не очень практичен в реальном мире.
Во-вторых, если это общее дерево файлов содержит двоичные файлы, и все добавили эти пути в свой $ PATH, то у вас вообще нет безопасности. Любой из ваших пользователей может угнать всю группу, так что всем им лучше доверять друг другу. Кроме того, вы используете NFS, так что если пользователи могут принять корень на своих рабочих станциях, они могут получать доступ к файлам хранилища, как любой пользователь, который им нравится.
Что касается идеи отзыва учетных записей пользователей, вы получаете это, удаляя их с локальной рабочей станции, где в любом случае хранился пароль для одного (верно?), потому что с NFS, файловый сервер не имеет понятия, какой пароль они ввели, только что ядро их рабочей станции сказал «Привет, я UID 502, делать эти вещи от моего имени».
Итак, прежде чем продвигать проблему в вашей организации, вы должны подумать о том, действительно ли вы можете выполнить то, что вы хотите.
Если вы хотите, чтобы версии программ были менее хаотичными, возможно, попросите вас установить их, принадлежащие администратору. Безопасность лучше, когда администратор контролирует все в $ PATH.
Если вам нужны отдельные учетные записи, чтобы вы могли видеть, кто меняет файлы, вам, возможно, придется пойти так далеко, как написание демона, чтобы следить за общим деревом с помощью INotify (я предлагаю записать его в Perl) и принудительно g + rwx бит после каждого «открытого» события, и установить UID после каждого «события записи».
Надеюсь, что это поможет...
-121--146303-Это не проблема S/W, и это не проблема Atom. У меня есть Atom 330 в качестве основной машины (D945GCLF2), работающей под управлением Arch Linux - и я только что сделал этот тест:
ttsiod@home ~/tmp
$ wget i.stack.imgur.com/fWwyu.png
--2014-10-29 14:30:08-- http://i.stack.imgur.com/fWwyu.png
Resolving i.stack.imgur.com (i.stack.imgur.com)... 103.31.7.31...
Connecting to i.stack.imgur.com (i.stack.imgur.com)|103.31.7.31|:80...
HTTP request sent, awaiting response... 200 OK
Length: 28576 (28K) [image/png]
Saving to: `fWwyu.png'
100%[==============================>] 28,576 --.-K/s in 0.06s
2014-10-29 14:30:09 (446 KB/s) - `fWwyu.png' saved [28576/28576]
ttsiod@home ~/tmp
$ wget http://i.stack.imgur.com/KQiJX.png
--2014-10-29 14:30:16-- http://i.stack.imgur.com/KQiJX.png
Resolving i.stack.imgur.com (i.stack.imgur.com)... 103.31.6.184
Connecting to i.stack.imgur.com (i.stack.imgur.com)|103.31.6.184|:80...
HTTP request sent, awaiting response... 200 OK
Length: 28212 (28K) [image/png]
Saving to: `KQiJX.png'
100%[==============================>] 28,212 --.-K/s in 0.06s
2014-10-29 14:30:17 (431 KB/s) - `KQiJX.png' saved [28212/28212]
ttsiod@home ~/tmp
$ identify KQiJX.png
KQiJX.png PNG 640x400 640x400+0+0 8-bit sRGB 28.2KB 0.000u 0:00.000
ttsiod@home ~/tmp
$ time compare -metric PHASH fWwyu.png KQiJX.png null:
0.191664
real 0m1.029s
user 0m2.863s
sys 0m0.177s
ttsiod@home ~/tmp
$ time compare -metric PHASH fWwyu.png fWwyu.png null:
0
real 0m1.027s
user 0m2.843s
sys 0m0.190s
Поэтому время, необходимое для сравнения двух изображений 640x400 на Atom330, на 1 секунду - намного быстрее, чем ваши 25 секунд.
В отсутствие выходных данных журнала strace -f , единственное, что я могу догадаться, это... плохое аппаратное обеспечение (может быть, пассивно охлаждаемый CPU, который понижает скорость во избежание возгорания?) или плохо скомпилированные двоичные файлы (например, без использования расширений MMX/SSE).
BTW, чтобы убедиться, что ядро не подавляет вас, сначала сделайте это (как корень):
for i in /sys/devices/system/cpu/cpu?/cpufreq/scaling_governor ; do
echo performance > $i
done
Я бы затем попытался контролировать температуру/частоту CPU во время теста - я предполагаю, что он опускается до небытия...
Для полноты, это ядро и сравните версии , которые я использовал в тесте выше:
ttsiod@home ~/tmp
$ egrep '^model.na|^flags' /proc/cpuinfo | sort -u
model name : Intel(R) Atom(TM) CPU 330 @ 1.60GHz
flags : fpu vme de tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat clflush dts acpi
mmx fxsr sse sse2 ss ht tm pbe syscall
nx lm constant_tsc arch_perfmon pebs
bts nopl aperfmperf pni dtes64 monitor
ds_cpl tm2 ssse3 cx16 xtpr pdcm movbe
lahf_lm dtherm
ttsiod@home ~/tmp
$ uname -a
Linux home 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13
CEST 2014 x86_64 GNU/Linux
ttsiod@home ~/tmp
$ compare --version
Version: ImageMagick 6.8.9-9 Q16 x86_64 2014-10-26 http://www.imagemagick.o
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC HDRI Modules OpenCL OpenMP
Delegates: bzlib cairo fontconfig freetype gslib jng jp2 jpeg lcms lqr ltdl
lzma pangocairo png ps rsvg tiff webp wmf x xml zlib
Это связано с путем, который вы используете inotifywatch , и путь работает сам инструмент. При запуске inotifywatch -r/tmp вы начинаете просматривать /tmp и все файлы, которые уже в нем . При создании файла в /tmp метаданные каталога обновляются и содержат номер inode нового файла, что означает, что изменение происходит в /tmp , а не /tmp/test-1 . Кроме того, поскольку /tmp/test-1 отсутствовал при запуске инотификационных часов , на них не установлено инотификационных часов. Это означает, что любое событие, которое происходит в файле, созданном после установки часов, не будет обнаружено . Вы можете понять это лучше, если вы видите это сами:
$ inotifywatch -rv /tmp &
Total of n watches.
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n
Если вы включили механизм трассировки на inotify _ add _ watch (2) , последняя команда даст вам количество часов, установленных inotifywatch . Это число должно совпадать с числом, заданным самим inotifywatch . Теперь создайте файл внутри /tmp и снова проверьте:
$ inotifywatch -rv /tmp &
Total of n watches.
$ touch /tmp/test1.txt
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n
Номер не увеличится, что означает, что новый файл не просматривается. Обратите внимание, что поведение отличается при создании каталога:
$ inotifywatch -rv /tmp &
Total of n watches.
$ mkdir /tmp/test1
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n + 1
Это связано с тем, как работает переключатель -r :
-r,--восстановительный: [...] Если новые каталоги создаются в отслеживаемых каталогах , они автоматически просматриваются.
Изменить: Я немного запутался между вашими двумя примерами, но в первом случае часы размещены правильно, потому что пользователь вызывает inotifywatch на ~/* (который развернут, см. don_crissti's комментарий здесь ). Домашний каталог также просматривается, поскольку ~/. * содержит ~/. . Теоретически он также должен содержать ~/.. , что в сочетании с переключателем -r должно привести к наблюдению за всей системой.
Однако можно получить имя файла, запускающего событие create в отслеживаемом каталоге, но, как я полагаю, inotifywatch не извлекает эту информацию (она сохраняется несколько глубже, чем имя каталога). inotify-tools предоставляет другой инструмент, называемый inotifywait , который может вести себя примерно так же, как inotify-watch , и предоставляет больше опций вывода (включая % f ,это то, что вы ищете здесь):
inotifywait -m --format "%e %f" /tmp
С главной страницы :
-format < fmt >Вывод в пользовательском формате с использованием printf-подобного синтаксиса. [...] Поддерживаются следующие преобразования:
% f: при возникновении события в каталоге оно будет заменено именем файла, вызвавшего событие .
% e: заменено на события, которые произошли, разделенные запятыми.
Кроме того, опция -m (монитор) будет поддерживать inotifywait после первого события, которое будет воспроизводить поведение, вполне аналогичное inotifywatch .