Если во время выполнения apt update вы встречаетесь с ошибкой при попытке прочитать список пакетов в репозитории:
The following signatures couldn't be verified because the public key is not available: NO_PUBKEY <key>
Рубрика: Debian
oracle java8 jdk
Ввиду того, что теперь нет возможности скачать deb пакет будем его создавать.
Для начала ставим необходимые пакеты
sudo apt install java-package java-common libgtk-3-dev libcairo-gobject2
Качаем jdk архив jdk-8u211-linux-x64.tar.gz с сайта оракла https://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html (нужна учетка, но её можно создать)
Создаем из архива deb пакет
make-jpkg jdk-8u211-linux-x64.tar.gz
Устанавливаем
sudo dpkg -i oracle-java8-jdk_8u211_amd64.deb
Смотрим версию
java -version java version "1.8.0_211" Java(TM) SE Runtime Environment (build 1.8.0_211-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode)
Если ставили до этого javа
update-alternatives --list java /usr/lib/jvm/java-8-openjdk-amd64/jre/bin/java /usr/lib/jvm/java-8-oracle/jre/bin/java /usr/lib/jvm/java-9-openjdk-amd64/bin/java /usr/lib/jvm/oracle-java8-jdk-amd64/jre/bin/java
Выбрать нужную
sudo update-alternatives --set java /usr/lib/jvm/oracle-java8-jdk-amd64/jre/bin/java
Удаление старых ядер ( linux-kernel ) одной командой
Тем, кому нужно срочно, вот, эта команда:
dpkg -l 'linux-*' | sed '/^ii/!d;/'"$(uname -r | sed "s/\(.*\)-\([^0-9]\+\)/\1/")"'/d;s/^[^ ]* [^ ]* \([^ ]*\).*/\1/;/[0-9]/!d' | xargs sudo apt-get -y purge
Читать далее «Удаление старых ядер ( linux-kernel ) одной командой»
Удалённый доступ/Терминальный сервер с помощью FreeNX
Добавляем репозиторий:
sudo add-apt-repository ppa:freenx-team
Т.к. ppa не для Maveric/Natty нету вводим (для maveric) :
sudo sed -i 's/maverick/lucid/g' /etc/apt/sources.list.d/freenx-team-ppa-maverick.list
Или правим в /etc/apt/sources.list.d/freenx-team-ppa-natty.list версию на lucid.
Обновляемся:
sudo apt-get update
Скачиваем по ссылке (http://www.nomachine.com/download-package.php?Prod_Id=2520) 3 файла и ставим их командой:
sudo dpkg -i *.deb
Система на вас поругается, но это так и надо вводим :
sudo apt-get -f install
Впринципе всё, ставим клиент и пробуем конектиться… 🙂
Драйверы для принтеров, сканеров и МФУ Samsung
Делаем из нетбука карманный web-сервер.
На данный момент мощность большинства мобильных устройств класса ноутбук или нетбук вполне достаточна для того, чтобы использовать их в качестве легкого, мобильного сервера. Я не вытерпел и сделал из своего нетбука Asus EeePC 900 сервер, который выступает в роли WEB-сервера (LAMP), хранилища для файлов (FTP) и кода (GIT, GitWeb)… И для этого достаточно пары-тройки часов времени, нетбук, интернет и дистрибутив Debian (в целом можно и другой, но я предпочитаю его, как простой и удобный).
Читать далее «Делаем из нетбука карманный web-сервер.»
Слово «виртуализация» уже не такое страшное или сервер виртуализации на новом уровне…
Продолжая свои изыскания в сфере виртуализации, однажды натолкнулся в интернете на информацию о Proxmox VE. Если вкратце — это решение для виртуализации, представляющее удобные инструменты для управления виртуальными машинами и сделанное на основе Debian.
Читать далее «Слово «виртуализация» уже не такое страшное или сервер виртуализации на новом уровне…»
MDADM. Битый диск – без паники!
Кто пользуется софтовым RAID-массивом, тому пригодится мой только-что обретенный опыт.
Началось все с того, что буквально три часа назад мой сервер меня обрадовал сообщением от mdadm. Смысл сообщения в том, что от второго массива был отсоединен один из дисков в результате ошибки.
После подключения было обнаружено, что к устройству /dev/md1 подключен только один из двух дисков. В том время как в системе второй диск и виден и функционирует. Слегка запаниковав, я пошел простым путем — почитав man mdadm, просто добавил к /dev/md1 устройство /dev/sdb1, которые и отсоединилось…
Но меня ждал жестокий сюрприз — mdadm после попытки синхронизировать диски выдал сообщение «faulty spare rebuilding». Первая мысль была — диск убился. Вторая мысль пришла через 5 минут — а не порытся ли в интернете. Мое спокойствие было вознаграждено и я почитал какой-то пост в интернете на английском языке, из которого понял в общих чертах, что в данном случае какая-то проблема со SMART.
Поставив пакет smartmontools, я вывел всю инфу по сбойному диску, в которой не нашел никаких отклонений. После некоторых раздумий, я запустил тест диска по команде smartctl —test=short /dev/sdb… Пришлось ждать целых 2 минут, пока закончится тестирование (сразу скажу, в примере написано про test-long, так вот я его советую запускать только при явных проблемах, т.к. работает он порядка 4-5 часов 🙂 ).
И «о чудо, Волька ибн не помню кто»! Тестирование не показало никаких отклонений на устройстве и я снова попытался подсоединить раздел к массиву… И был таки вознагражден наблюдением неуклонно растущего процента синхронизации без ошибок.
Вывод очень простой: даже если Вы не используете SMART, его показатели зачастую все равно влияют на работоспособность устройств, поэтому для профилактики все таки периодически запускайте тестирование и проверку SMART-статуса устройств. Ошибок возможно не будет, но при этом скорее всего перестанут паниковать другие программы.
Это страшное слово – «виртуализация». Часть третья, заключительная. У страха глаза велики.
Итак, настал момент истины, и я пишу заключительную часть про виртуализацию.
Для тех, кто не в курсе, здесь первая часть (в которой я описываю, с чего все началось и как сделать), здесь вторая часть (в которой я предостерегаю от некоторых технических ошибок). Ну а сейчас пойдет речь о том, что же делать, если приходится переустановливать систему (к примеру мигрируя на другую платформу) и напоследок небольшая фотосессия.
Итак, с чего же я начну… Став счастливым обладателем еще 4Гбайт оперативной памяти, 2-х терабайтников от WD и пары вентиляторов, я пришел к мысли, что надо не просто поставить все это в сервер, но и заодно воспроизвести ситуацию с переустановкой системы.
Для начала напомню и дополню свою конфигурацию сервера:
— процессор AMD Phenom X4 9550 SocketAM2+ (2.20GHz, 4Mb, 1800MHz) (я сторонник AMD, так уж вышло);
— плата MB ASUS sAM2+ M3A78 AMD 770 DDR2 ATX (выбирал по доступности и с наличием RAID, что в итоге оказалось не совсем корректным, читайте в первой части);
— оперативная память 8Гбайт (всего четыре планки по 2Гб, максимум для материнки);
— жесткие диски, 4 по 1Тб (объединены по два в RAID-1, один на более отказоустойчивых для активной работы, второй на попроще дисках для малоиспользуемых файлов относительно первого);
— операционная система Debian Lenny x86_64.
Перед тем, как переустанавливать, я естественно сохранил настроечные документы. И вы не забудьте тоже их сохранить, дабы заново не изобретать велосипед.
Что же изменилось, помимо добавления в аппаратной начинке? А изменению у меня подвергнутся виртуальные настройки. Я заранее распределю на разные сетевые карты виртуалки по признаку активности с внешним миром, повесив на отдельную сетевую карту внешние. Описывать там особо нечего, кроме того, что для этого я создал два бриджа, вместо одного и при настройке виртуальной машины прописывал нужный бридж. Плюс ко всему я перетаскиваю rtorrent с виртуальной на хостовую машину, т.к. столкнулся с неприятными особенностями работы nfs при большом кол-ве открытых файлов. Количественно это может и не много, около 200 одновременно открытых файлов, но от этого начинались жуткие тормоза раздачи, что меня не устраивало.
Как установить чистую систему, не потеряв нужных данных, вы и без меня знаете наверняка. Остановлюсь на важных и болезненных моментах, по моему мнению:
— виртуальные машины воспроизвелись без проблем, путем простого наката папки /etc/libvirt из бекапа (изменения вступили в силу после перезагрузки, единственное что поправил — это пути до образов жестких дисков и названия бридж-интерфейсов);
— при настройке второго рейда не торопитесь его использовать, лучше дождитесь окончательной синхронизации (хотя пользоваться им можно и сразу, но из-за фоновой синхронизации будут ощутимые потери в производительности).
Хм… что-то мало болезненных моментов, не правда ли? Ну так не забываем, что перед нами операционная система Linux, которая гораздо гибче и стабильнее Windows, так что сомнений быть больше у Вас не должно. В остальном никаких проблем не возникло, так что смело можете при необходимости переставлять систему, не боясь потерь.
Напоследок несколько фото, как выглядит в живую и со стороны ПО мой сервер (за качество не ругайте, снято на коммуникаторе):
Это страшное слово – «виртуализация». Часть вторая. Не повторяйте чужих ошибок.
Получив в распоряжение мощный инструмент в виде сервера виртуализации я сразу попытался по максимуму его задействовать в своих задачах.
Попользовав его в достаточном количестве, обнаружил некоторые тонкости и нюансы, которыми и хочу с вами поделиться.
1. Если предполагаете использовать серверы раздельно для сети и для интернета, лучше сразу запланировать/приобрести/настроить минимум две сетевые карты. Во-первых, работать будет шустрее. После разделения на две сетевые карты скорость по внутренней сети стала около 10Мбайт/с, тогда как в случае единственной сетевой карты скорость скакала от 2 до 6Мбайт/с. Во-вторых, как выяснилось, на уже настроенной на один интерфейс виртуальной машине при смене активного интерфейса начинаются непонятные явления, потери пингов и т.п. (Windows Server вообще потерял сеть, например, а rtorrent просто зависал).
2. Разделяйте на разные физические разделы данные, используемые с ощутимо разной интенсивностью. Т.е. если вы планируете раздавать файлы по пиринговой сети, ftp и локальной сети, то лучше сохранять эти файлы на отдельном разделе, по минимуму смешивая с теми, которые используются другими виртуальными машинами. Благо современные средства монтирования файловых систем позволяют в одну папку монтировать одновременно несколько физических разделов.
3. Если вы используете в качестве гостевой системы Linux, то по возможности приближайте ее к варианту, который стоит на хосте. Т.е. в моем случае это Debian Lenny. Сервер LAMP+FTP+Ubuntu работал относительно нестабильно в плане сетевой активности, в отличие от связки LAMP+FTP+Debian…
4. Если планируется очень большая активность файловых операций (типа раздача более 100 торрентов одновременно), то советую в этом случае отказаться от использования виртуальной машины и настроить сервер непосредственно на хосте. Это позволит избежать значительных потерь в производительности (к примеру хешироваться файл для торрент-раздачи на хосте будет раз в 10 быстрее, чем в виртуальной машине через nfs).