Обычно задача ставится так:
У клиента и у сервера есть точки входа, позволяющие чётко выделить трафик от/к клиента и к/от серверу. Однако, хочется сделать так, чтобы никто не мог понять, что этот конкретный клиент обратился к этому конкретному серверу.
Прокси делает так, что точка входа клиента - видит трафик от клиента к прокси и обратно; а точка входа сервера - видит трафик от прокси к серверу и обратно. А вот увязать эти два вида трафика (понять, что они связаны, что они по сути один трафик) - может только сам прокси.
Конечно, если этот прокси обслуживает только одного клиента - то точка входа прокси это легко отследит (если она знает, на что обращать внимание). Но если клиент обращается в разные места, а прокси обслуживает много клиентов, обращающихся к разным серверам - то понять, какой клиент к какому серверу обращался, довольно сложно, зачастую нереально.
2) Далеко не всегда предупреждения позволяют предотвратить ущерб. Особенно если в системе есть всякие уязвимости.
3) Выдача логов ВК (силами админов) посторонним людям - вообще никак не соотносится с предупреждениями. Хотя бы потому, что все ограничения доступа - на админов не влияют.
Ну, скорее всего, в ВК можно вставить ссылку на картинку на внешнем сервере - "IMG SRC=..."; ну а там картинку будет генерировать программа.
Вставить программу fly в ВК - я думаю, невозможно. Хотя там м.б. своя аналогичная программа.
Вставить Canvas (это часть JavaScript) в ВК - скорее всего, нельзя. Социальные сети - не место для программирования, ибо админы там туповатые, сделать безопасную модель программирования не могут, а опасная модель программирования прозволит хакерам воровать личнве данные юзеров и осуществлять незаконный доступ, в т.к. публиковать спам от имени других юзеров (я говорю про то, что обычно называют "взлом чужих эккаунтов").
Условие "картинка - в ВК" надо было огласить в вопросе. Оно очень существенное.
Попробуйте поискать в ВК сообщество, подходящее для таких вопросов. Ибо тут условие "ВК" первичнее/важнее, чем "генерация картинки".
PS: Мне кажется, генерировать картинку с текстом не имеет смысла. Проще сгенерировать текст в нужном оформлении. Этот вариант безопаснее, чем программирование - поэтому, скорее всего, он доступен.
Причина такого стыда в том что производители бегут за модой на радиосвязь. При этом ни производители, ни клиенты не понимают, что радиоэфир - он один на всех, и его пропускная способность конечна. Так что всё, что только можно - надо делать на кабелях, а по радио цеплять только то, что по кабелям ну вообще никак. К тому же кабели - ещё и безопаснее, к ним труднее подцепиться.
Увы, но после краха СССР - всё деградирует, и на Западе тоже. Особенно деградирует инженерная школа, всё больше власть берут гуманитарии, лирики, менеджеры - а они физически не способны понять законы физики.
Вопрос в том, как проверять owner. Я набросал такой вариант:
^[a-z0-9][a-z0-9-]{0,37}[a-z0-9]$
т.е. "в начале и в конце - не минус" ну и "в середине - до 37 букв, цифр или минусов". Но тут нет проверки на двойной минус. И отдельно надо оговорить однобуквенный вариант:
^[a-z0-9]|([a-z0-9][a-z0-9-]{0,37}[a-z0-9])$
Как видите - регекс стремительно разрастается и усложняется. А я выполнил не все требования топиккастера. Причём последнее требование - "отрицающее" (grep для этого использует ключ -v). И тут я забуксовал.
Для начала надо бы выяснить - это Samba-сервер переводит всё в один регистр, или же Windows-клиент? Проверьте, создав рас'share'нную папку на Windows-компьютере. Посмотрите список рас'share'нных папок командой 'net view'. Что-то мне кажется - описанное Вами поведение является стандартом.
PS: Я советую по мере сил использовать латинские названия и рас'share'нных папок, и всего остального. А в идеале - рас'share'нные папки надо скрывать, и пусть люди обращаются к ним, зная их названия. В частности, это иногда частично спасает от зловредов, шифрующих файлы.
Владимир Коротенко, То, что идея "дебильная" - я написал выше. Но ведь витает; впрочем, там витает много других дебильных идей, и многие даже реализуются.
С бесконечной лентой - сервер должен определить, какие картинки прислать сразу. Я думаю, если посмотреть устройство этой ленты, то станет ясно, что надо присылать сразу: в этой идее просто парсится HTML на стороне сервера.
С динамическими бандлами - наверно, ничего присылаться заранее не будет, ибо бандлы формирует JS, а не простой HTML.
Вообще-то, в воздухе витает дебильная идея о том, что если клиент просит HTML-страничку, то сервер должен сразу (без запроса от клиента) выдать ему заодно все картинки, которые упомянуты в этой страничке, а также все странички, куда можно перейти с этой странице по клику мышкой.
Я сказал "дебильная" - ибо это сразу убьёт напрочь весь эффект кэширования: картинки будут пихаться клиенту независимо от того, есть ли они в кэше клиента.
В документации в квадратных скобках пишут необязательный параметр команды. А в скрипте - да, это команда "test", возвращающая код завершения в зависимости от результата (например, в зависимости от того, существует ли файл с таким именем).
Обычно используется в таком виде:
if [ -f файл ] ...
Википедия - как раз для людей с минимальными знаниями. Чисто чтобы освоить, чт за термин, из какой области, по каким словам гуглить дальше. Ну и прямые ссылки там часто есть.
SSI позволяет создать какой-то кусок HTML-страницы и включить его во все страницы, где он нужен. Например, навигационная плашка, которая д.б. на каждой странице сайта.
Этот "кусок HTML-страницы" м.б. как статическим, так и результатом работы скрипта - например, чтобы страница выделяла тот пункт навигации, коорый указывает на неё саму.
Сейчас это можно сделать с применением CSS - чтогда оно не "Server Side Includes", а "Client Side Includes". Но SSI создавали, когда CSS ещё не было.
Ещё SSI позволяет автоматически дописывать в HTML-страницу размер какого-то файла. Это нужно для ссылок, по которым скачивают большие файлы.
Посмотрите какие-нибудь хорошие книги по Web-серверу Apache. Собственно, SSI родились именно там.
ps -ax | grep winbindd | grep -v grepэто очень плохое решение. См.мой ответ ниже.Вместо можно
/usr/local/etc/rc.d/samba start