Natrio Сообщения

Natrio	# 4 года, 7 месяцев назад (отредактировано 4 года, 7 месяцев назад)
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	indeviral А есть разница?)) Есть, есть разница, в зависимости от того, как всё это настроено (чистые модули wpa_supplicant@ и dhcpcd@, либо netctl, либо wicd или NM и т.д. anode На первой машине Wi-Fi клиент надо интернет с него пробросить на Ethernet. Мост (bridge) сработает только в том случае, если вайфайный модуль на уровне прошивки позволяет включить "неразборчивый" режим (promiscuous mode), то есть принимать пакеты, адресованные не ему. В этом случае на первой машине оба интерфейса (назовём их wlan0 и eth0) нужно добавить в мост (br0), и уже на этом br0 запускать dhcpcd, а на второй машине запускать dhcpcd на интерфейсе локалки. Если с мостом ничего не выйдет (допустим, вайфайный модуль не поддерживает "неразборчивый" режим), можно включить на первой машине форвардинг `sysctl net.ipv4.ip_forward=1` и настроить на обеих статические IP-адреса в отдельной, не совпадающей с локалкой, подсети. Дефолтный роут на второй машине должен указывать на первую. Чтобы запросы со второй машины правильно обрабатывались в локалке, на первой нужно применить к ним маскарадинг, в iptables это делается так: `iptables -t nat -A POSTROUTING -i eth0 -j MASQUERADE` В обоих случаях, в зависимости от сетевых карточек проводной сети, если они будут соединяться напрямую, без свича, может понадобиться (а может и не понадобиться) обжимать его по варианту кроссовер, то есть чтобы вход первой на выход второй, и наоборот.

# 4 года, 7 месяцев назад (отредактировано 4 года, 7 месяцев назад)

Сообщения: 4763

Участник с: 08 января 2011

indeviral
А есть разница?))

Есть, есть разница, в зависимости от того, как всё это настроено (чистые модули wpa_supplicant@ и dhcpcd@, либо netctl, либо wicd или NM и т.д.

anode
На первой машине Wi-Fi клиент надо интернет с него пробросить на Ethernet.

Мост (bridge) сработает только в том случае, если вайфайный модуль на уровне прошивки позволяет включить "неразборчивый" режим (promiscuous mode), то есть принимать пакеты, адресованные не ему. В этом случае на первой машине оба интерфейса (назовём их wlan0 и eth0) нужно добавить в мост (br0), и уже на этом br0 запускать dhcpcd, а на второй машине запускать dhcpcd на интерфейсе локалки.

Если с мостом ничего не выйдет (допустим, вайфайный модуль не поддерживает "неразборчивый" режим), можно включить на первой машине форвардинг

sysctl net.ipv4.ip_forward=1

и настроить на обеих статические IP-адреса в отдельной, не совпадающей с локалкой, подсети. Дефолтный роут на второй машине должен указывать на первую.
Чтобы запросы со второй машины правильно обрабатывались в локалке, на первой нужно применить к ним маскарадинг, в iptables это делается так:

iptables -t nat -A POSTROUTING -i eth0 -j MASQUERADE

В обоих случаях, в зависимости от сетевых карточек проводной сети, если они будут соединяться напрямую, без свича, может понадобиться (а может и не понадобиться) обжимать его по варианту кроссовер, то есть чтобы вход первой на выход второй, и наоборот.

Natrio	# 4 года, 7 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	Для начала надо разобраться, как настроена сать на первой машине, и чем вы подключаете к ней вторую.

Natrio	# 4 года, 7 месяцев назад (отредактировано 4 года, 7 месяцев назад)
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	Вот тут пишут, что для записи параметров GRUB в BTRFS требуется нечто, называемое "reserved area". Никогда не пользовался BTRFS, так что не знаю, что это. grubenv write support (used to track failed boot entries) is lacking, grub needs btrfs to support a reserved area. GRUB, строго говоря, имеет модули различных ФС только для чтения. Сохранение параметров требует перезаписи содержимого файла "grubenv". Поскольку записывать ФС GRUB на самом деле не умеет, используется трюк: файл "grubenv" заранее создаётся с фиксированной длиной в 1024 байта, то есть содержимое всегда меньше, оставшийся "хвост" заполняется символами "#". Чтобы сохранить параметры, GRUB находит на диске сектор с содержимым этого файла, и изменяет его, не трогая остальные данные ФС. Весь этот фокус можно проделать только в том случае, если ФС хранить содержимое файла в неизменном виде. Если файловая система как-то упаковывает содержимое файла, изменить его средствами загрузчика не получится.

Natrio

# 4 года, 7 месяцев назад (отредактировано 4 года, 7 месяцев назад)

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

Вот тут пишут, что для записи параметров GRUB в BTRFS требуется нечто, называемое "reserved area". Никогда не пользовался BTRFS, так что не знаю, что это.

grubenv write support (used to track failed boot entries) is lacking, grub needs btrfs to support a reserved area.

GRUB, строго говоря, имеет модули различных ФС только для чтения.
Сохранение параметров требует перезаписи содержимого файла "grubenv".

Поскольку записывать ФС GRUB на самом деле не умеет, используется трюк: файл "grubenv" заранее создаётся с фиксированной длиной в 1024 байта, то есть содержимое всегда меньше, оставшийся "хвост" заполняется символами "#".
Чтобы сохранить параметры, GRUB находит на диске сектор с содержимым этого файла, и изменяет его, не трогая остальные данные ФС.

Весь этот фокус можно проделать только в том случае, если ФС хранить содержимое файла в неизменном виде. Если файловая система как-то упаковывает содержимое файла, изменить его средствами загрузчика не получится.

Natrio	# 4 года, 7 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	Вы обрезали лог, так что ошибки компилятора не видно. Однако, судя по boost-libs в зависимостях, видимо, пакет сломался после обновления этой библиотеки.

Natrio	# 4 года, 7 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	Вращающееся, то бишь жесткий диск. Видимо, контроллер флешки представляется как USB-HDD.

Natrio	# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	red оно ? Нет, конечно, там же написано: Base Package: dropbear Description: Lightweight SCP executable Upstream URL: https://matt.ucc.asn.au/dropbear/dropbear.html License(s): MIT Conflicts: openssh Если кто не в курсе, dropbear это "лёгкий" эрзац-SSH для систем с дефицитом ресурсов, вроде роутеров. Применяется там же, где busybox. А у нас, в Арче, используется нормальный, "взрослый" openssh, и scp всегда был его частью: `$ pacman -Ql openssh \| grep /bin/ openssh /usr/bin/ openssh /usr/bin/findssl.sh openssh /usr/bin/scp openssh /usr/bin/sftp openssh /usr/bin/ssh openssh /usr/bin/ssh-add openssh /usr/bin/ssh-agent openssh /usr/bin/ssh-copy-id openssh /usr/bin/ssh-keygen openssh /usr/bin/ssh-keyscan openssh /usr/bin/sshd $ pacman -Ss '^openssh$' core/openssh 7.6p1-1 [установлен] Free version of the SSH connectivity tools`

Natrio

# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

red
оно ?

Нет, конечно, там же написано:

Base Package: dropbear
Description: Lightweight SCP executable
Upstream URL: https://matt.ucc.asn.au/dropbear/dropbear.html
License(s): MIT
Conflicts: openssh

Если кто не в курсе, dropbear это "лёгкий" эрзац-SSH для систем с дефицитом ресурсов, вроде роутеров. Применяется там же, где busybox.

А у нас, в Арче, используется нормальный, "взрослый" openssh, и scp всегда был его частью:

$ pacman -Ql openssh | grep /bin/
openssh /usr/bin/
openssh /usr/bin/findssl.sh
openssh /usr/bin/scp
openssh /usr/bin/sftp
openssh /usr/bin/ssh
openssh /usr/bin/ssh-add
openssh /usr/bin/ssh-agent
openssh /usr/bin/ssh-copy-id
openssh /usr/bin/ssh-keygen
openssh /usr/bin/ssh-keyscan
openssh /usr/bin/sshd
$ pacman -Ss '^openssh$'
core/openssh 7.6p1-1 [установлен]
    Free version of the SSH connectivity tools

Natrio	# 4 года, 8 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	red как по мне всё очевидно "1" "1/" "1/." "1/./" "1/./." и т.д. – эквивалентны, это один и тот же путь, указывающий (очевидно?) именно на каталог "1", а не на что-то иное. cd (оператор шелла, в bash и zsh ) воспринимает их все (1 и 1/.) как раз одинаково, но не о нём речь, поскольку он принимает только каталог как аргумент. Нас же интересуют только те команды, которые принимают как аргумент и файлы, и каталоги, а потому могут интерпретировать "/." в конце как указание на все файлы в каталоге, как это делает cp , в место самого каталога, Итак, мы уже выяснили, что команда mv (из того же пакета coreutils), в отличии от cp , вообще не может интерпретировать путь с "/.", и всегда выдаёт ошибку. Таким образом, mv не может переместить все файлы в другой каталог через обозначение "/." Команда rm -r , которая тоже принимает как файлы, так и каталоги, принципиально отказывается принимать пути с точкой (.) или двумя (..) на конце, из соображений безопасности. То есть, rm не может удалить все файлы в каталоге через это обозначение. Команда readlink -f (из coreutils), успешно удаляет из пути все лишние одинарные точки, и никакого специально значения им не придаёт, что от неё и ожидается. Команда ls тупо передаёт аргумент (или точку при отсутствии аргумента) ядру, а потому наличие или отсутствие лишних точек в конце пути не влияет на получаемый от ядра список (ядро выдает все файлы в каталоге, включая "скрытые", и включая виртуальные "." и ".."), но влияет на выводимый результат – ls так же тупо дописывает путь к каждому полученному от ядра имени. Другими словами, список файлов выводится независимо от точки в конце пути. Команда ln -s (жесткие ссылки на каталоги запрещены) аналогично mv , выдаёт ошибку, если в конце первого аргумента стоит точка, но только если каталог назначения существует. В противном случае работает так же, как и без точки. То есть, точка в конце пути и здесь не означает список файлов. Ладно, сдаюсь – мне не удалось припомнить в пакете coreutils ни одной команды, кроме cp, которая бы интерпретировала точку в конце пути таким специфическим (для меня) и таким очевидным (для вас) способом. Кстати, с scp я вчера что-то перепутал – она как раз работает аналогично cp Зря вы о ней так пренебрежительно – мало того, что эта команда на вашей стороне, так ещё и входит в [core], как часть пакета openssh. Зачем вы записали её в [community]? При всём при этом, использование шаблона * в шелле работает со всеми командами безотказно. Отключение фильтрации "скрытых", работает одинаково и в баше ( shopt -s dotglob , включение shopt -u dotglob ), и в zsh ( setopt globdots , включение setopt noglobdots ). Шаблон *{,.}* работает только в zsh, который получая от ядра список имён для шаблона, выкидывает из него виртуальные, аналогично ls -A Было бы здорово, если бы все пользовались zsh, а не башем, да? :) По поводу мнения Роба Пайка о "дотфайлах" – можно сетовать на ошибки авторов UNIX сколько угодно, реальность от этого не изменится – они есть, и приходится как-то с ними жить. Ну, или может с ними побороться – например, прописать в rc-файле zsh перманентные команды `setopt globdots alias ls='ls --color=auto -A'` Вуаля, теперь все файлы в консоли равны!

Natrio

# 4 года, 8 месяцев назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

red
как по мне всё очевидно

"1" "1/" "1/." "1/./" "1/./." и т.д. – эквивалентны, это один и тот же путь, указывающий (очевидно?) именно на каталог "1", а не на что-то иное.

cd (оператор шелла, в bash и zsh ) воспринимает их все (1 и 1/.) как раз одинаково, но не о нём речь, поскольку он принимает только каталог как аргумент.

Нас же интересуют только те команды, которые принимают как аргумент и файлы, и каталоги, а потому могут интерпретировать "/." в конце как указание на все файлы в каталоге, как это делает cp , в место самого каталога,

Итак, мы уже выяснили, что команда mv (из того же пакета coreutils), в отличии от cp , вообще не может интерпретировать путь с "/.", и всегда выдаёт ошибку. Таким образом, mv не может переместить все файлы в другой каталог через обозначение "/."

Команда rm -r , которая тоже принимает как файлы, так и каталоги, принципиально отказывается принимать пути с точкой (.) или двумя (..) на конце, из соображений безопасности. То есть, rm не может удалить все файлы в каталоге через это обозначение.

Команда readlink -f (из coreutils), успешно удаляет из пути все лишние одинарные точки, и никакого специально значения им не придаёт, что от неё и ожидается.

Команда ls тупо передаёт аргумент (или точку при отсутствии аргумента) ядру, а потому наличие или отсутствие лишних точек в конце пути не влияет на получаемый от ядра список (ядро выдает все файлы в каталоге, включая "скрытые", и включая виртуальные "." и ".."), но влияет на выводимый результат – ls так же тупо дописывает путь к каждому полученному от ядра имени. Другими словами, список файлов выводится независимо от точки в конце пути.

Команда ln -s (жесткие ссылки на каталоги запрещены) аналогично mv , выдаёт ошибку, если в конце первого аргумента стоит точка, но только если каталог назначения существует. В противном случае работает так же, как и без точки. То есть, точка в конце пути и здесь не означает список файлов.

Ладно, сдаюсь – мне не удалось припомнить в пакете coreutils ни одной команды, кроме cp, которая бы интерпретировала точку в конце пути таким специфическим (для меня) и таким очевидным (для вас) способом. Кстати, с scp я вчера что-то перепутал – она как раз работает аналогично cp
Зря вы о ней так пренебрежительно – мало того, что эта команда на вашей стороне, так ещё и входит в [core], как часть пакета openssh. Зачем вы записали её в [community]?

При всём при этом, использование шаблона * в шелле работает со всеми командами безотказно. Отключение фильтрации "скрытых", работает одинаково и в баше ( shopt -s dotglob , включение shopt -u dotglob ), и в zsh ( setopt globdots , включение setopt noglobdots ).
Шаблон {*,.*} работает только в zsh, который получая от ядра список имён для шаблона, выкидывает из него виртуальные, аналогично ls -A
Было бы здорово, если бы все пользовались zsh, а не башем, да? :)

По поводу мнения Роба Пайка о "дотфайлах" – можно сетовать на ошибки авторов UNIX сколько угодно, реальность от этого не изменится – они есть, и приходится как-то с ними жить. Ну, или может с ними побороться – например, прописать в rc-файле zsh перманентные команды

setopt globdots
alias ls='ls --color=auto -A'

Вуаля, теперь все файлы в консоли равны!

Natrio	# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	red, уважаю ваше упорство :) ~~Самому на старости лет было тяжело узнать, что поведение шаблонов управляемо.~~ "Звёздочка" без шаманства захватывает "скрытые" файлы и каталоги, достаточно разрешить ей это: shopt -s dotglob Ваша гипотеза об автоматическом "выкидывании" . и .. командой cp не оправдывается (тем более, что она получает от баша не шаблоны, а уже раскрытый список путей, явно содержащий все варианты раскрытия): $ mkdir /tmp/test $ cd /tmp/test $ mkdir -p 1/2/3 1/.hid 2 $ touch 1/.h $ echo 1/{,.} 1/2 1/. 1/.. 1/.h 1/.hid $ cp --recursive --verbose 1/{,.} 2 '1/2' -> '2/2' '1/2/3' -> '2/2/3' cp: предупреждение: каталог-источник '1/.' указан более одного раза '1/./.hid' -> '2/./.hid' '1/./.h' -> '2/./.h' cp: жёсткая ссылка '2/1' на каталог '2/.' не будет создана cp: невозможно скопировать каталог '1/..' в самого себя, '2' '1/.h' -> '2/.h' пример явно делает много лишнего. Что касается второго, копирующего 1/. , он действительно работает, хотя и очень неочевидным способом, то есть в данном случае как раз имеет место "костыль" внутри команды cp: путь "*каталог/." (формально эквивалентный "каталог" ) воспринимается как указание копировать содержимое вместо самого каталога, если каталог назначения существует (если не существует, всё работает так же, но уже вполне ожидаемо). P.S.* Кроме того, костыль внутри cp никаки не поможет с другими командами, к примеру mv так уже не умеет: `$ mv -v 1/. 2 mv: невозможно переместить '1/.' в '2/.': Устройство или ресурс занято` Команда scp воспримет "путь/". как эквивалент "путь", и сработает почти как cp, с одним забавным отличием – прежнее содержимое каталога назначения будет уничтожено.

Natrio

# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

red, уважаю ваше упорство :) ~~Самому на старости лет было тяжело узнать, что поведение шаблонов управляемо.~~
"Звёздочка" без шаманства захватывает "скрытые" файлы и каталоги, достаточно разрешить ей это: shopt -s dotglob

Ваша гипотеза об автоматическом "выкидывании" . и .. командой cp не оправдывается (тем более, что она получает от баша не шаблоны, а уже раскрытый список путей, явно содержащий все варианты раскрытия):

$ mkdir /tmp/test
$ cd /tmp/test
$ mkdir -p 1/2/3 1/.hid 2
$ touch 1/.h
$ echo 1/{*,.*}
1/2 1/. 1/.. 1/.h 1/.hid
$ cp --recursive --verbose 1/{*,.*} 2
'1/2' -> '2/2'
'1/2/3' -> '2/2/3'
cp: предупреждение: каталог-источник '1/.' указан более одного раза
'1/./.hid' -> '2/./.hid'
'1/./.h' -> '2/./.h'
cp: жёсткая ссылка '2/1' на каталог '2/.' не будет создана
cp: невозможно скопировать каталог '1/..' в самого себя, '2'
'1/.h' -> '2/.h'

пример явно делает много лишнего.

Что касается второго, копирующего 1/. , он действительно работает, хотя и очень неочевидным способом, то есть в данном случае как раз имеет место "костыль" внутри команды cp: путь "каталог/." (формально эквивалентный "каталог" ) воспринимается как указание копировать содержимое вместо самого каталога, если каталог назначения существует (если не существует, всё работает так же, но уже вполне ожидаемо).

P.S.
Кроме того, костыль внутри cp никаки не поможет с другими командами, к примеру mv так уже не умеет:

$ mv -v 1/. 2
mv: невозможно переместить '1/.' в '2/.': Устройство или ресурс занято

Команда scp воспримет "путь/". как эквивалент "путь", и сработает почти как cp, с одним забавным отличием – прежнее содержимое каталога назначения будет уничтожено.

Natrio	# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	Под шаблон .* попадут, в том числе, . (текущий каталог) и .. (родительский каталог). Очень не советую так делать. На самом деле, всё просто :) 1) вместо всех этих --recursive и т.д., используйте cp -a 2) чтобы шаблон * включал в себя "скрытые" файлы и каталоги, нужно просто переключить поведение шаблонов shopt -s dotglob cp -a /path/from/* /path/to/ Нет, . и .. под этот шаблон не попадут. Чтобы вернуть нормальное поведение в текущей сессии баша, опцию можно отключить той же командой с ключом -u shopt -u dotglob Подробнее об опциях шаблонов баша смотрите, например, тут. Из других интересных возможностей – можно отключить чувствительность шаблонов к регистру: `shopt -s nocaseglob ls *.jpg` В этом примере будут выведены файлы, оканчивающиеся и на .jpg, и на .JPG

Natrio

# 4 года, 8 месяцев назад (отредактировано 4 года, 8 месяцев назад)

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

Под шаблон .* попадут, в том числе, . (текущий каталог) и .. (родительский каталог). Очень не советую так делать.

На самом деле, всё просто :)
1) вместо всех этих --recursive и т.д., используйте cp -a
2) чтобы шаблон * включал в себя "скрытые" файлы и каталоги, нужно просто переключить поведение шаблонов

shopt -s dotglob
cp -a /path/from/* /path/to/

Нет, . и .. под этот шаблон не попадут. Чтобы вернуть нормальное поведение в текущей сессии баша, опцию можно отключить той же командой с ключом -u

shopt -u dotglob

Подробнее об опциях шаблонов баша смотрите, например, тут.
Из других интересных возможностей – можно отключить чувствительность шаблонов к регистру:

shopt -s nocaseglob
ls *.jpg

В этом примере будут выведены файлы, оканчивающиеся и на .jpg, и на .JPG

Natrio	# 4 года, 8 месяцев назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	Скорей всего, в конфиге груба неправильно задан (или оставлен абстрактный по-умолчанию) UUID, вот ничего и не находит. Но вам же дана консоль после [rootfs /]# , и её вполне достаточно, чтобы выяснить – видит оно вашу флешку, или нет. Достаточно blkid , или `ls -l /dev/disk/by-uuid/` или `ls -l /dev/disk/by-id/usb*`

Natrio

# 4 года, 8 месяцев назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

Скорей всего, в конфиге груба неправильно задан (или оставлен абстрактный по-умолчанию) UUID, вот ничего и не находит.
Но вам же дана консоль после [rootfs /]# , и её вполне достаточно, чтобы выяснить – видит оно вашу флешку, или нет. Достаточно blkid , или

ls -l /dev/disk/by-uuid/

или

ls -l /dev/disk/by-id/usb*