Это меньше похоже на хак, более явно указывается на то, что DEST это именно имя в которое нужно копировать. Плюс у некоторых файловых систем может не быть директорий .. и .
Чтобы убрать только определённый аттрибут достаточно указать паттерн опцией -m для getfattr, и/или можно подправить строку с setfattr, чтоб уж точно только этот аттрибут удалял [[ "${line}" == 'yourattrname' ]] && setfattr ....
Как-то уж слишком мудрёно на мой вкус получилось, я б использовал что-то такое:
remove_all_user_xattrs_in /this/dir
#!/bin/bash
path=$1
while IFS= read -r line; do
case "${line}" in
'') continue;;
'# file: '*) filename=${line:8};;
*) setfattr -hx "${line}" "${filename}"
printf '%s: %s\n' "${filename}" "${line}"
esac
done < <(getfattr -hPR --absolute-names -- "${path}")
Этот скрипт/сниппет уберёт все расширенные аттрибуты пользователя в заданой директории (первый аргумент) и скажет какие именно убрал. Если хотите удалить вообще все, надо добавить -m - к аргументам getfattr.
Под Linux можно убрать сохранение расширенных пользовательских аттрибутов смонтировав раздел с опцией nouser_xattr, если файловая система это поддерживает. ext* поддерживают.
Под Linux всё уже написано за нас, пакет с утилитами называется attr (в деривативах Debian во всяком случае).
Найти файлы в домашней директории у которых выставлены какие-нибудь расширенные аттрибуты можно так:
getfattr -dRhm- /home 2>/dev/null >./getfattr.log
Удалить ненужный аттрибут:
setfattr -hx name /path/to/comrade/major.png
Чтобы удалить всё и вся надо заскриптить чуток, не нашёл ключа удаляющего все аттрибуты скопом.
Не браузерами едиными. Например, клиент Slack сохраняет user.xdg.origin.url, EiskaltDC++ пишет в user..gltth, другие программы тоже могут использовать эту фичу.
Думаю вполне можно сделать, чтобы это почти не ощущалось. Я это представляю, как тонкий слой износоустойчивого тонкого гибкого прозрачного пластика (толщиной где-то как тонкий маленький полиэтиленовый пакет), который приклеен к клавишам и пространству между ними. В колхозном варианте можно просто на клавиатуру положить слой тонкого пластика (плёнки) и нагреть его, чтобы он подрасплавился и прилип к кнопкам и межкнопочному пространству. Apple вполне может подобрать более технологичный процесс и материалы.
Тут, мне кажется, не совсем обычные проценты, когда речь идёт о бесконечностях. Вот, например, сколько процентов занимают рациональные числа от вещественных? Или удобнее будет спросить какой процент от комплексных занимают вещественные? Вспомнив поле комплексных чисел и линию вещественных на нём, очевидно, что 0%, тем не менее чисто вещественные числа всё-таки встречаются в комплексных.
Не придирайтесь к спорным территориям. Абхазия тоже не совсем Грузинская, и т.п. Для текущей стадии проекта это не так важно, мне кажется. Можно просто отсылки дать на основе каких данных сформированы именно такие границы (может они и есть где-то уже).
Кстати, эту информацию, если есть, можно показывать в информационном блоке.
Смотря какая маршрутизация и где. Первому пакету откуда?
Например знаю, что в ядре Linux начиная с 3.6 отключили по-умолчанию кэш маршрутов по каким-то причинам, теперь, как понимаю, маршрут для каждого пакета вычисляется заново по таблице(цам) маршрутизации.
Почему не делают пыле- (а за одно и влаго-) защиту на клавиатуру? Мне кажется не очень сложно добавить тоненькую гибкую прослойку по краям клавиш соединив их с корпусом. Это бы решило все проблемы добавив весьма полезную защиту от «кофе».
Я не про отдельные силиконовые накладки на всю клавиатуру, которые сильно портят ощущение от нажатия.
Кто скажет насколько безопасен данный способ с ProxyCommand, если на промежуточном server1 сидит злодей под рутом и жаждет расширить сферу своего влияния на тебя.
Как я понимаю это получше, чем агента прокидывать, но безопасно ли проделывать такое с не доверенными хостами?
В критически важных CI/CD использование комбинации ssh-keyscan example.com >> ~/.ssh/known_hosts
Во время инициализации совместно с StrictHostKeyChecking=yes
Позволит надежно защититься от MITM-атак
Это же совсем не так, man ssh-keyscan говорит:
SECURITY
If an ssh_known_hosts file is constructed using ssh-keyscan without verifying the keys, users will be vulnerable to man in the middle attacks. On the other hand, if the security model allows such a risk, ssh-keyscan can help in the detection of tampered keyfiles or man in the middle attacks which have begun after the ssh_known_hosts file was created.
Т.е. без верификации ключа ты уязвим к MITM.
Или я что-то недопонимаю в вашем высказывании?
Да, в статье это указано. Если есть желание можно дополнить статью способами оптимизации.
Дополню предыдущий свой коммент:
Если разделить всё IPv4 пространство на 32 диапазона, и добавить для каждого из них правило смотреть свою таблицу маршрутизации, то 85000 маршрутов из большой общей таблицы превращаются в таблицы по 2-3 тысячи маршрутов, порядок уже совсем другой, любой роутер должен сдюжить. Правда не знаю хорошо ли это вливается в концепцию работы BGP в данной статье (не использовал ни разу).
Ну, тут проверять надо. Если роутер загибается от такого обилия маршрутов можно попробовать другое решение. Знаю что частенько бывает, что кастомные прошивки на OpenWrt/LEDE часто не поддерживают тот самый "кремниевый сахар" устройств.
Кстати, большую таблицу маршрутизации тоже можно разбить на более мелкие диапазоны теми же правилами маршрутизации ip rule — тоже может полегчать.
Возможно для роутера будет не так напряжно маркировать пакеты файерволом (iptables с ipset) исходя из соединения, а маршрутизировать уже на базе этой маркировки (ip rule). Сам не проверял, но при таком подходе проходить по куче айпишников придётся не для каждого пакета, а только для первого пакета в соединении.
Это меньше похоже на хак, более явно указывается на то, что
DEST
это именно имя в которое нужно копировать. Плюс у некоторых файловых систем может не быть директорий..
и.
Мне кажется вместо этого лучше использовать опцию
-T
:cp -a -T /source /target
В некоторых случаях ещё полезен флаг
-t
, только тогдаsource
иtarget
меняются местами:Чтобы убрать только определённый аттрибут достаточно указать паттерн опцией
-m
дляgetfattr
, и/или можно подправить строку сsetfattr
, чтоб уж точно только этот аттрибут удалял[[ "${line}" == 'yourattrname' ]] && setfattr ...
.Как-то уж слишком мудрёно на мой вкус получилось, я б использовал что-то такое:
Этот скрипт/сниппет уберёт все расширенные аттрибуты пользователя в заданой директории (первый аргумент) и скажет какие именно убрал. Если хотите удалить вообще все, надо добавить
-m -
к аргументамgetfattr
.Под Linux можно убрать сохранение расширенных пользовательских аттрибутов смонтировав раздел с опцией
nouser_xattr
, если файловая система это поддерживает.ext*
поддерживают.Под Linux всё уже написано за нас, пакет с утилитами называется
attr
(в деривативах Debian во всяком случае).Найти файлы в домашней директории у которых выставлены какие-нибудь расширенные аттрибуты можно так:
Удалить ненужный аттрибут:
Чтобы удалить всё и вся надо заскриптить чуток, не нашёл ключа удаляющего все аттрибуты скопом.
Не браузерами едиными. Например, клиент Slack сохраняет
user.xdg.origin.url
, EiskaltDC++ пишет вuser..gltth
, другие программы тоже могут использовать эту фичу.Кстати, эту информацию, если есть, можно показывать в информационном блоке.
Например знаю, что в ядре Linux начиная с 3.6 отключили по-умолчанию кэш маршрутов по каким-то причинам, теперь, как понимаю, маршрут для каждого пакета вычисляется заново по таблице(цам) маршрутизации.
Я не про отдельные силиконовые накладки на всю клавиатуру, которые сильно портят ощущение от нажатия.
Кто скажет насколько безопасен данный способ с
ProxyCommand
, если на промежуточномserver1
сидит злодей под рутом и жаждет расширить сферу своего влияния на тебя.Как я понимаю это получше, чем агента прокидывать, но безопасно ли проделывать такое с не доверенными хостами?
Это же совсем не так,
man ssh-keyscan
говорит:Т.е. без верификации ключа ты уязвим к MITM.
Или я что-то недопонимаю в вашем высказывании?
Вот тоже просто, тоже без докера, одной командой: https://github.com/vmspike/openvpn-manage
Да, в статье это указано. Если есть желание можно дополнить статью способами оптимизации.
Дополню предыдущий свой коммент:
Если разделить всё IPv4 пространство на 32 диапазона, и добавить для каждого из них правило смотреть свою таблицу маршрутизации, то 85000 маршрутов из большой общей таблицы превращаются в таблицы по 2-3 тысячи маршрутов, порядок уже совсем другой, любой роутер должен сдюжить. Правда не знаю хорошо ли это вливается в концепцию работы BGP в данной статье (не использовал ни разу).
Ну, тут проверять надо. Если роутер загибается от такого обилия маршрутов можно попробовать другое решение. Знаю что частенько бывает, что кастомные прошивки на OpenWrt/LEDE часто не поддерживают тот самый "кремниевый сахар" устройств.
Кстати, большую таблицу маршрутизации тоже можно разбить на более мелкие диапазоны теми же правилами маршрутизации ip rule — тоже может полегчать.
Возможно для роутера будет не так напряжно маркировать пакеты файерволом (
iptables
сipset
) исходя из соединения, а маршрутизировать уже на базе этой маркировки (ip rule
). Сам не проверял, но при таком подходе проходить по куче айпишников придётся не для каждого пакета, а только для первого пакета в соединении.