System administration matters in general
По умолчанию для подсети 192.168.2.0/24 пакеты идут через интерфейс 192.168.1.2, но мы хотим, чтобы поле src пакетов для определенного dst (в нашем примере – это хост 192.168.2.10) было 192.168.1.3.
Для этого не применяя iptables (который работает на сетевом уровне (Network Layer) модели OSI), можно применить команду ip route, которая всё сделает быстрее, на Link Layer’e:
ip route add 192.168.2.10/32 via 192.168.2.1 dev eth0 src 192.168.1.3
Но для скриптования или удаленного доступа может пригодиться команда для добавления нетворк алиасов в cmd:
netsh -c Interface ip add address name=”Local Area Connection” addr=192.168.1.9 mask=255.255.255.0
А также для их удаления:
netsh -c Interface ip delete address name=”Local Area Connection” addr=192.168.1.9
Где name – это название сетевого адаптера, например, в Центре управления сетями / Сетевые подключения. Адрес и маска – понятно.
Команда требует административных привелегий, конечно же.
Ссылки:
dpkg -i somepackage.deb
Теперь установим не удовлетворенные зависимости с помощью команды:
Если у вас после загрузки Windows 8/8.1 вылазить такое пустое окошко с ошибкой Explorer.exe:
это значит, что у вас скорее всего backdoor или иной вирус прописал себя в автозагрузку вместе с процессом Explorer.exe.
Лечится это следующим образом:
Открываем Run (Win + R) и запускаем редактор реестра regedit.
Там находим ключ HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWindowsLoad и смело удаляем его. Всё, теперь эта ошибка вас беспокоить перестанет (не забудьте также изжить вирус, прописавшийся там с помощью, например, бесплатного сканера Kaspersky Virus Removal Tool).
Поможет в этом следующая консольная команда:
ps auxw | grep postgres | grep — -D
Для начала, необходимо узнать PID засшей службы или процесса.
C:Windowssystem32>sc queryex nscp
SERVICE_NAME: nscp
TYPE : 10 WIN32_OWN_PROCESS
STATE : 4 RUNNING
(STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
WIN32_EXIT_CODE : 0 (0x0)
SERVICE_EXIT_CODE : 0 (0x0)
CHECKPOINT : 0x0
WAIT_HINT : 0x0
PID : 544
А теперь команда для завершения процесса:
C:>taskkill /PID 544 /F
eject /dev/cdrom
Если, при этом выдаётся следующая ошибка:
eject: unable to eject, last error: Inappropriate ioctl for device
То нужно попробовать следующую последовательность команд:
file /dev/sr0
Конфигурационных файлов в /etc он не имеет, в init.d его тоже нет. Чтобы его настроить делаем следующее:
1. Нужно дописать опцию Enable=true в секции “xdmcp” конфига /etc/gdm3/daemon.conf для Gnome 3.
2. Заходим в консоль под нашим десктопным пользователем и вызываем окно настроек Vino:
vino-preferences
Откроется окно вроде такого:
Где указываем отмечаем галочки и устанавливаем пароль.
Также в опции vino можно зайти через апплет Desktop Sharing или Remote Desktop (смотря какой дистрибутив).
Если отметить опцию Configure network automatically to accept connections, то vino будет открывать порт на роутере (если там разрешен UPnP) 5900 наружу, в Интернет, что обычно не желательно.
3. Запускаем собственно демона:
export DISPLAY=:0.0
xhost +/usr/lib/vino/vino-server &
netstat -nl | grep 5900
Последняя команда служит для проверки того, что vino запустился и слушает порт 5900.
4. Теперь с другой машины, которая имеет доступ к нашей пробуем подключиться (для Windows это можно сделать при помощи бесплатных программ TightVNC или UltraVNC).
Настройки по-умолчанию должны сработать.
5. Теперь проблема в том, что vino не стартует со стартом системы и не имеет скрипта запуска. И стартовать он должен с тем пользователем, на который планируется удалённый вход. Для этого нужно добавить в файл /home/username/.bashrc в конец следующие строчки:
export DISPLAY=:0.0
/usr/lib/vino/vino-server &
UPDATE:
Обнаружил, что при таком тексте .bashrc каждый раз, когда открываешь терминальную сессию, то vino ругается в консоль, что он уже запущен. Посему необходимо изменить текст на следующий, включающий в себя проверку:
export DISPLAY=:0.0
ps cax | grep vino-server > /dev/null
if [ $? -ne 0 ]; then
/usr/lib/vino/vino-server &
fi
Ссылки:
Недавно приключилась такая беда – у мышки фирмы A4Tech X5 стало глючить колёсико – при прокручивании колёсиком картинка дергается вверх-вниз. Мышка мне очень нравится и выбрасывать её было жалко. К тому же решение проблемы нашлось в интернете.
Пишут, что этот бок проявляется в течении полгода-года на многих мышках фирмы A4Tech и лечится следующим образом:
1. Разбираем мышку (обычно путем откручивания пары болтов внизу)
2. Находим механизм колесика и аккуратно вытаскиваем колесико вместе с осью на которой оно сидит (отгибаем слегка вверх и вытаскиваем). Видим нечто похожее как на картинке:
3. Стрелками указаны металлические зажими, который надо подогнуть к механизму. Я сделал это кусачками, можно утконосами, маленькими плоскогубцами или чем-нибудь похожим – но без сильного фанатизма, чтобы не сломать! 🙂
4. Собираем всю конструкцию воедино и наслаждаемся нормальной работой колёсика.
Ссылки: