Давайте снимать скор за некропостинг. А то уже надоело. Думаешь, что это новая интресная тема, кликаешь, а там оказывается старое и засохшее говно. Портится от этого настроение. Особенно, когда такое происходит утром. Весь день может пойти на смарку.
Проблема проста. Есть ноутбук подключенный к сети через WiFi.
Надо обеспечить доступ виртуальной машины на QEMU в эту же сеть.
Я понимаю, что для этого теоретически, надо создать tap сетевой адаптер и создать мост включающий его и сетевую карту, через которую реальная машина подключена к сети.
Вот тут и проблема - нельзя просто взять и создать мост с WiFi картой. Или как-то можно?
Подскажите пожалуйста. Возможно есть другие пути?
Виртуалка просто должна работать в реальной сети как еще один компьютер.
Интересует именно QEMU, как это сделать с Virtualbox я знаю, но он не подходит.
#####РЕШЕНИЕ#######
Спасибо 
Pinkbyte! Я осилил по твоему совету.
Включаем Proxy ARP
# sysctl net.ipv4.conf.all.proxy_arp=1
Включаем IP Forwarding
# sysctl net.ipv4.ip_forward=1
Создаем tap сетевой интерфейс, доступный для пользователя (важно! qemu работает от пользователя !)
# tunctl -p -t tap0 -u <username>
Создаем маршрут для ip адреса виртуалки через tap0
ip route add 192.168.1.199 dev tap0
Запускаем QEMU с параметрами сети
-netdev tap,id=mynet0,ifname=tap0,script=no,downscript=no -device virtio-net-pci,netdev=mynet0
На гостевой системе - настраиваем статический ip адрес 192.168.1.199.
После этого все работает, виртуалка видна по своему адресу снаружи как отдельный компьютер.
Просто почитайте этот пост как маленький рассказ, покритикуйте, предложите лучшие решения и было бы круто узнать что-то новое. Я всё делал на AlmaLinux 8.5.
Наверняка не всякий домохозяин знает о том, что пока он смотрит ютуб, устанавливает-удаляет программы, играет в игры и бох знает что ещё делает, в это время его компьютер усердно пишет логи почти всей активности в его системе. Обычно это простые текстовые файлы, но бывают ещё сжатые и даже бинарные.
Если ты, дорогой линуксоид, ещё не интересовался этой проблемой, то я тебе скажу вот что: интернет полон историй, где у людей подобная отчётность программ съедала сотни гигабайт совершенно бесполезными текстами.
Понимаю, это всё очень нужные вещи для разработчиков, ведь случись чего — как помочь человеку?! Вот так и помогают: просят прислать лог программы и всё такое. Ну ещё всяким админам и прочим специалистам позарез надо, причём с длинной историей, чтоб на недели, а то и месяцы была записана вся активность системы и программ. Только здесь возникает вопрос, а нафига это домашнему пользователю, который установил линукс, настроил программы и сидит тихо. Такой человек, если обои ему не понравились (я уж не говорю о багах), решает свои проблемы сменой дистрибутива.
Начну с эпичного ~/.xsession-errors. Этот наверное чемпион по поглощению дискового пространства. Поскольку я гномосек, то мне он никогда не мешал особо, ибо gdm как-то хитро и аккуратно с ним работает и он не наполняется лишней информацией (кроме того, если его удалить пару раз, то он больше не появляется, магия…). Но вот тут поковырялся в кедах и обнаружил, что этот самый файл растёт как на дрожжах, а растёт потому, что всё, что программы выхлопывают в stderr пишется в него, и это какой-то звиздец, товарищи.
(Сразу скажу, что если ты не знаешь, как выключить какой-нибудь лог и лень разбираться, то обычно проканает сделать ссылку в /dev/null, типа ln -s /dev/null ~/.xsession-errors, а ещё делают более жёстко: cp -a /dev/null /var/log/долбанный.log, есть и другие варианты, но думаю хватит и этих)
А фишка с этим файлом в том, что «добрые люди» поместили скрипт в Xsession (дело было с sddm):
# redirect errors to a file in user's home directory if we can
if [ -z "$GDMSESSION" ]; then
# GDM redirect output itself in a smarter fashion
errfile="$HOME/.xsession-errors"
if ( umask 077 && cp /dev/null "$errfile" 2> /dev/null ); then
chmod 600 "$errfile"
[ -x /sbin/restorecon ] && /sbin/restorecon $errfile
exec > "$errfile" 2>&1
else
errfile=$(mktemp -q /tmp/xses-$USER.XXXXXX)
if [ $? -eq 0 ]; then
exec > "$errfile" 2>&1
fi
fi
fi
Я его закомментировал и на этом конец :-)
Вообще полезно бывает открыть терминал на всю длину экрана, запустить там journalctl -f и помониторить, что у тебя да как. И вот тут, пользуясь случаем, хочу высказать свой огромный респект кедерастам. Да, они зачем-то по умолчанию врубают дебаггинг своего окружения на полную и это будет видно в журнале, но он отключается. Можно в /etc/environment или ~/.bash_profile написать QT_LOGGING_RULES='*=false' и на это всё закончится, красавчики, чё.
А вот гномосеки и gtk-шники вертели тебя на ***, хоть обгуглись — решения нет, все эти мерзкие ворнинги и прочий хлам видимо так и будут засирать наши терминалы до второго пришествия. Если хочешь чистый терминал, то либо пиши после каждой gtk-шной софтины 2>/dev/null, либо мути с альясами и функциями в ~/.bashrc. А как быть с журналом не понятно, пока не придумал. Подскажите что-нибудь.
Ещё раз, пользуясь случаем, хочу высказать респект и уважуху разрабам хромых браузеров, они хотя бы о терминале позаботились (пиши --log-level=3 и будет счастье), а вот журнал спасти не удастся.
Поговорим теперь про coredump-ы. Серьёзно, кто-нибудь из домашних юзеров вообще это читал или посылал куда-нибудь?! А они работают! Благо, это всё отключается, однако тоже не без некоторой фигни. Кароче, чтобы выключить надо в /etc/systemd/coredump.conf прописать:
Storage=none
ProcessSizeMax=0
Только вот, как я понял, сам процесс создания этих штук не прекратится, хоть они и не будут ничего нигде занимать. Да, там в манах пишут как это решить, но сам ты, простой домашний юзверь, зуб даю, хрен найдёшь. Я натнулся на просторах интернетов на самого Лёню Потного, где он всё и объяснил. Прямо скажем, решение выглядит как говно:
sudo ln -s /dev/null /etc/sysctl.d/50-coredump.conf
Ты не поверишь, но именно это предлагается в манах.
Пришло время поговорить о каталоге /var/log… На мой миопический взгляд, это ещё один эпический трындец. Загляни туда, бро, это же какая-то вакханалия логов, и мне что-то подсказывает, что ты, домашний пользователь, читать их никогда не будешь. Ладно-ладно, знаю, бывает надо, но фишка в том, что почти всё это тупо дублирует systemd-journald, который сам хранит свои логи, производит над ними ротацию и всё такое, а здесь идет дублирование демоном rsyslog, который туда складывает логи, а другой демон — logrotate — производит над ними ротацию.
Что касается программ rsyslog и logrotate (последняя может пригодится, если хочешь какой-то лог хранить и иметь ротацию), решай сам, я вот просто взял да и удалил, и программы и все логи из /var/log, чтобы тупо посмотреть, что осталось (об этом, когда про dnf).
Надо ли хранить на диске наш православный системдешный журнал? Мне вот не надо, всё что было до этой загрузки системы, мне не интересно. Можно просто выделить ему немного памяти и всё — пока система работает, лог есть, выключил, лога нет. Надо написать в /etc/systemd/journald.conf
Storage=volatile
RuntimeMaxUse=16M
16 мегов вроде хватает.
На закуску про DNF. Это ещё один товаришь в стиле GTK & GNOME, типа нам так удобнее, а вы идите лесом. Так вот, после разгрома дирректории /var/log, там осталась небольшая кучка логов, в общем безобидные и мелкие, но среди них четыре засранца:
dnf.log
dnf.rpm.log
dnf.librepo.log
hawkey.log
Про эти логи тоже в интернетах не мало историй. Да, их можно обрабатывать вышеназванной программой logrotate, но мне это не надо, я их не читаю ни-ког-да! Эти логи продуцирует DNF и на багзилле шляпы есть чудный интеллигентный срачик с разрабами, которые всё сводят к тому, что логи пусть пишутся, мы по ним помогаем людям, а то что их отключить нельзя, это мол dnf так стремительно разрабатывается, что походу некогда (видимо у разрабов GTK дела обстоят также) :-)
Кароче, решения нет, только кувалдой, то есть в /dev/null.
Доступные сборки:
Доступные архитектуры:
Для работы сборок нужен как минимум GLIBC 2.27. Скрипт, которым я компилирую Wine, а также актуальная информация о сборках (опции компилирования, применяемые патчи и прочее), доступны на GitHub. Обновляю по мере возможности.
Старые сборки (4.11 и старее) требуют как минимум GLIBC 2.23.
Как использовать эти сборки? Просто распакуйте в домашний каталог (или в /opt) и указывайте путь до бинарника wine при запуске приложений. Например:
/home/user/wine-4.0-amd64/bin/wine someapp.exeСсылки на скачивание:
Если вам нужны сборки со встроенными библиотеками, взгляните на другой мой проект: https://github.com/Kron4ek/wine-portable-executable
Вот такой вопрос.
Резюме: https://shdown.github.io/resume.pdf
Ожидаемая ЗП: от $1000 в месяц.
Писать на shdownnine at gmail.com.
Для интересующихся (номера 22-29 были RFRemix)
# cat /boot/upgrade/upgrade_fedora_23_24_31_32.txt
22->23
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-23-$(uname -i)
# dnf upgrade
# dnf clean all
# dnf --releasever=23 --setopt=deltarpm=false distro-sync
23->24
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-24-$(uname -i)
# dnf upgrade
# dnf clean all
# dnf --releasever=24 --setopt=deltarpm=false distro-sync
29->31
на время обновления поставить в параметры ядра при загрузке selinux=0
отключить все русские репо, т.к. они уже не поддерживатся
отключить остальные неосновные репо
удалить chromium и другие конфликтующие пакеты, которые будут далее выявлены
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-31-primary
# dnf upgrade --refresh
# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --refresh --releasever=31 --skip-broken --allowerasing
# dnf system-upgrade reboot
После обновления.
# dnf distro-sync
Почистить старые пакеты по указанной инструкции
# https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
установить загрузку grub2 на верхний пункт "навсегда".
grub2-set-default 0
Т.к. из-за введённой системы "blscfg" grub2 перестал запоминать последний загруженный пункт
P.S. после штатного обновления проблему с blscfg решили.
31->32
# rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-32-primary
# dnf upgrade --refresh
# dnf install dnf-plugin-system-upgrade
# dnf system-upgrade download --refresh --releasever=32 --skip-broken --allowerasing
# dnf system-upgrade reboot
После обновления.
# dnf distro-sync
Почистить старые пакеты по указанной инструкции
# https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/
Если сломался запуск dnfdragora,
то необходимо удалить или переименовать старый файл настроек
по адресам:
для всех: /etc/dnfdragora/dnfdragora.yaml
для root: /root/.config/dnfdragora.yaml
для пользователя: /home/user/.config/dnfdragora.yaml
Взываю в первую очередь к тов. alpha. Что тут происходит? Вот в этом треде удалили мой коммент по причине 4.8 дискуссия не на русском языке. Вот текст моего сообщения:
Ну сколько можно?
В самом деле, сколько можно пользоваться сраным третьегномом? Почему бы не заюзать нормальную оболочку, где это можно нормально настроить один раз и забыть про пердолинг с раскладками (и прочим юзабилити)?
Я все таки читать умею. Где тут «не русский язык»?
Я понятие не имею каким образом мне подступиться к этому вопросу. Где вообще найти хоть какие-то настройки этой стадии загрузки ОС? Это главная проблема, но есть и другие: не видно звёздочки при вводе пароля для расшифровки корневой системы; если после 3-х неудачных попыток ввода пороля я расшифровываю директорию в rescueshell, то при вводе пути к корневой фс initramfs не подхватывает её(раньше подхватывал). Каюсь, я не знаю, что можно приложить к топику, так что если не хватает информации - сообщайте, приложу. gentoo-ядро 4.19.86, genkernel 4.0.1(с помощью него генерировал initramfs)
Обращать внимание на amd?