Отличный пост про aptitude

Очень подробно и с примерами описан поиск в aptitude в частности и работа с ним вообще. То что нужно для домашнего сервера!

Webmin

Для тех, кому не хочется добавлять пользователей (или делать что-то еще) на сервере ручками, придумали Webmin. Эта штука позволяет заходить на сервер из браузера и делать все, что угодно. Установка- вполне простая. Взято с UbuntuGeek.

Надо скачать последнюю версию отсюда, например так:

$ wget http://prdownloads.sourceforge.net/webadmin/webmin_1.480_all.deb

Установить на сервере необходимые пакеты:

$ sudo aptitude install perl libnet-ssleay-perl openssl libauthen-pam-perl libpam-runtime libio-pty-perl libmd5-perl

Установить на сервере собственно Webmin:

$ sudo dpkg -i webmin_1.480_all.deb

Использование- еще проще.

В браузере коннектимся к серверу:

https://your-server-ip:10000

И заходим с логином, который позволяет делать sudo:


Webmin будет сразу использовать sudo.

Установка Perforce (клиент Ubuntu)

В одном из предыдущих постов я написал как установить Perforce на сервер. В этом посте речь пойдет о клиенте на Убунту.

1. Переходим в директорию, куда скачали p4. Делаем файл исполняемым и переносим в директорию /usr/local/bin:

$ sudo chmod +x p4
$ sudo mv p4 /usr/local/bin

2. Есть несколько способов сообщить клиенту, где искать сервер. Например, можно определить P4PORT и прочие переменные в файле /etc/profile, как для сервера. Мы же воспользуемся наиболее удобным- файлом с настройками. Perforce ищет файл настроек в текущей директории, если не находит, ищет в родительской директории и т.д. Создадим файл .p4config и запишем его в директорию с проектами, например /home/alex/projects:
P4CLIENT=alex-ws
P4EDITOR=gedit
P4PORT=192.168.0.180:1666
P4USER=alex

Теперь все проекты в этой директории будут использовать одни и те же настройки:

3. Сообщаем p4, как узнать имя файла настроек- редактируем /etc/profile:

$ gksu gedit /etc/profile

Добавляем в конец этого файла:
export P4CONFIG=.p4config

4. Создаем спецификацию клиента:

$ p4 client

[update]
5. Проверяем:

$ p4 info
User name: alex
Client name: alex-ws
Client host: alex-laptop
Client root: /home/alex/Projects
Current directory: /home/alex
Client address: 192.168.0.183:38973
Server address: 192.168.0.180:1666
Server root: /perforce_depot
Server date: 2009/08/24 22:04:50 -0500 CDT
Server uptime: 00:39:30
Server version: P4D/LINUX26X86/2009.1/208599 (2009/07/23)

Изменить Timezone

Вот тут нашел, как это делается на сервере Ubuntu:

$ sudo dpkg-reconfigure tzdata

Стрелочками выбираем нужную страну/город, жмем Ok, все!

Установка Perforce (сервер)

На прошлой работе мы использовали Perforce, на теперешней- Clear Case и Subversion. Ну, Clear Case- это просто чудовищный монстр, а Subversion как-то странно смотрится после Perforce. К хорошему быстро привыкаешь, и я решил поставить Perforce дома. Лицензия на его использование не нужна, если число пользователей не больше двух, а рабочих пространств (workspace)- не более пяти. Должно хватить. Если в будущем не хватит, перейду на git.

Установка довольно подробно описана в Perforce System Administrator's Guide и прочих документах. Пример установки можно найти здесь, хотя он и не без ошибок. Я придерживался именно его, корректируя ключевые места по официальной документации. Вот что получилось.

Скачиваем Perforce с офф-сайта, нам понадабятся и сервер (p4d), и клиент (p4). Я также скачал грфические клиенты p4v для Windows и Linux (они пригодятся позже), а потом скопировал p4 и p4d на сервер через самбу.

Часть 1. Установка

Установка выполняется из-под рута. Дальше все команды начинаются с sudo, сейчас имеет смысл переключиться на root с помощью sudo su.

1. Переходим в директорию, куда скопировали p4 и p4d. Делаем их исполняемыми и переносим в директорию /usr/local/bin:

$ sudo chmod +x p4 p4d
$ sudo mv p4d /usr/local/bin
$ sudo mv p4 /usr/local/bin

2. Создаем суперпользователя perforce и группу p4admin. Суперпользователь perforce должен быть в группе p4admin:

$ sudo adduser perforce
$ sudo addgroup p4admin
$ sudo usermod -g p4admin perforce

3. Разрешаем суперпользователю perforce запускать sudo.

$ sudo visudo

Добавляем в конец файла строку
perforce ALL = ALL

4. Создаем директорию для хранения журнала и лога perforce:

$ sudo mkdir /var/log/perforce

5. Создаем директорию для хранения всей базы. Желательно держать базу на отдельном винте на случай, если винт сбойнет, тогда базу можно будет восстановить из журнала. У меня винт только один, так что без изысков:

$ sudo mkdir /perforce_depot

6. Изменяем права на исполняемые файлы и только что созданные директории. Нам нужно, чтобы пользователь perforce имел все права, а остальные- только на чтение и исполнение:

$ sudo chown perforce:p4admin /usr/local/bin/p4d
$ sudo chown perforce:p4admin /usr/local/bin/p4
$ sudo chown perforce:p4admin /perforce_depot
$ sudo chown perforce:p4admin /var/log/perforce
$ sudo chmod 755 /usr/local/bin/p4d
$ sudo chmod 755 /usr/local/bin/p4
$ sudo chmod 755 /perforce_depot
$ sudo chmod 755 /var/log/perforce

7. Записываем наши настройки в /etc/profile:

$ sudo vim /etc/profile

Добавляем в конец этого файла:
# Perforce Settings
export P4JOURNAL=/var/log/perforce/journal
export P4LOG=/var/log/perforce/p4err
export P4PORT=localhost:1666
export P4ROOT=/perforce_depot
export P4USER=perforce

8. Заставляем Perforce стартовать вместе со всей системой:

$ sudo apt-get install daemon
$ cd /etc/init.d
$ sudo vim perforce

Копируем туда вот эти строки:
#!/bin/sh -e

export P4JOURNAL=/var/log/perforce/journal
export P4LOG=/var/log/perforce/p4err
export P4ROOT=/perforce_depot
export P4PORT=1666

PATH="/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin"

. /lib/lsb/init-functions

p4start="p4d -d"
p4stop="p4 admin stop"
p4user=perforce

case "$1" in
start)
log_action_begin_msg "Starting Perforce Server"
daemon -u $p4user $p4start;
;;

stop)
log_action_begin_msg "Stopping Perforce Server"
daemon -u $p4user $p4stop;
;;

restart)
stop
start
;;

*)
echo "Usage: /etc/init.d/perforce (start|stop|restart)"
exit 1
;;

esac

exit 0

Изменяем права на файл perforce. Замечу, что этот файл дожен принадлежать root:

$ sudo chmod 755 perforce

Часть 2. Первый запуск.

Загружаемся как пользователь perforce и выполняем следующие команды.

1. Загружаем настройки:

$ sudo source /etc/profile

2. Запускаем сервер в бэкграунде (не из-под root):

$ p4d &

3. Создаем журнал:

$ p4d -jc

4. Устанавливаем права доступа для пользователей (я этого не делал, т.к. я- один-единственный реальный пользователь)- редактируем Perforce Protection Specification:

$ p4 protect

5. Создаем клента и сохраняем файл:

$ p4 client

6. Проверяем наши установки:

$ p4 info

7. Останавливаем сервер Perforce:

$ p4 admin stop

Осталось только перегрузить сервер.

Впечатления от ccache

ccache- это кешируещий препроцессор исходников. Основная идея состоит в том, чтобы выяснить, не собираемся ли мы компилировать тот же самый код снова, и если да, то просто воспользоваться уже сгенерированным кодом и, таким образом, сэкономить кучу времени. Уверяют, что часто компиляция осуществляется в 5-10 раз быстрее. Вот тут написано за счет чего это достигается.

Народ, кто пользуется distcc, очень активно интересовался, а будет ли distcc работать в паре с ccache? Ответ был дан такой: да, но только в простом (не-pump) режиме. Поскольку, pump меня не устраивает, я решил попробовать, а вдруг что-нибудь путное получится из использования ccache?

Развитие ccache остановилось пять лет назад, поэтому последнюю версию можно ставить из репозитариев. Не знаю в чем дело, но на моей машине после этого слетели настройки рендеринга шрифтов, так что осторожнее с этой командой:

$ sudo apt-get install ccache

Update: После переустановки Ubuntu , я сначала поставил все GNOME приложения, ccache, и только после это библиотеки и приложенияKDE. Может быть дело было именно в порядке установки, но теперь со шрифтами все нормально.

Использование ccache простое- вместо просто make надо делать

$ make 'CC=ccache gcc'

Если есть желание подружить его с distcc, то в установке distcc ничего менять не надо, а собирать надо так:

$ make -j40 'CC=ccache distcc gcc'

Я проверял, как всегда, на vim 7.2. Существенная разница есть между временем компиляции просто make и с использованием ccache:
Make без ccache и distcc- 2 мин 17 сек.
С использованием ccache без distcc- 1 мин 57 сек.
С использованием distcc без ccache, только на сервере- 1 мин 51 сек.
С использованием distcc без ccache, на localhost и сервере- 1 мин 10 сек.
С использованием ccache и distcc, на localhost и сервере- 1 мин 10 сек.

Отсутствие выиграша по времени в последним случае можно объяснить медленным процессором, который выполняет ccache и даже небольшим размером проекта vim. Но, с учетом проблем со шрифтами, желание работать с ccache отпало.

Существует похожий проект cachecc1, ориентированный только на gcc. Из статистики, приведенной на оффсайте следует, что cachecc1 в целом дает лучшие результаты, чем ccache, иногда превосходя его в разы по времени компиляции. Будем копать.

distcc 3.1-1 и переменные окружения

Для экспериментов с distcc очень удобно использовать переменную DISTCC_HOSTS. Ее distcc проверяет первой, а за ней уже файлы ~/.distcc/hosts и /etc/distcc/hosts. Так что если надо быстро добавить или убрать компилирующий хост, то делаем:

$ export DISTCC_HOSTS='localhost 192.168.0.180'

Проверяем:

$ distcc --show-hosts

Чтобы вернуться к списку хостов, записанному в файле hosts, делаем

$ unset DISTCC_HOSTS

Существует еще одна переменная, тоже перечисляющая компилирующие хосты- DISTCC_POTENTIAL_HOSTS. Она используется в режиме pump, о котором речь идет в предыдущем посте. Как следует из названия переменной, смысл ее в том, что она перечисляет все хосты, которые могут использоваться для компиляции:

$ export DISTCC_POTENTIAL_HOSTS='localhost 192.168.0.180,cpp 192.168.0.200,cpp,lzo'

Перед началом компиляции, если переменная DISTCC_HOSTS не определена, скрипт pump (а точнее, lsdistcc) проверит, доступны ли хосты, перечисленные в этой переменной, и есть ли работающий distcc демон на этих хостах. Список хостов, прошедших проверку, будет сохранен в переменной DISTCC_HOSTS, которая будет использоваться distcc, как раньше.

Параметр ,cpp указывает, что для данного сервера должен быть включен режим pump. Параметр ,lzo указывает, что инклюды должны упаковываться перед пересылкой данному серверу.

distcc 3.1-1 и pump mode

Ну вот добрались и до pump mode. Что это за зверь? Это режим, который заставляет удаленный хост компилировать не только C/C++ файлы, но и хедеры. Подробно разница между pump и простым режимом работы distcc изложена в man по distcc. Режим pump, по идее, серьезно ускоряет компиляцию, поскольку обработка хедеров перенесена с localhost на сервер(ы).

Но этот подход также создает и ряд проблем. Понятно, что во время компиляции исходные файлы проекта не должны меняться, но это-то как раз не препятствие для большинства проектов. Гораздо серьезнее, что pump не будет работать, когда на localhost и сервере находятся разные инклюды в /usr/include или /usr/local/include/. Такое может легко получиться после установки нескольких программ. Проблема идентифицирована разработчиками как "enhancement" со средним уровнем приоритета. Тем не менее, я решил попробовать использовать режим pump.

В списке компилирующих хостов надо указать, что хост будет использоваться в режиме pump и, опционально, что инклюды надо паковать перед отправкой на сервер. Делается это добавлением параметров cpp и lzo через запятую к имени/айпишнику хоста в списке:

192.168.0.180,cpp,lzo

Список хостов может быть указан в файле hosts или в переменных среды. Об этом- отдельный пост.

Перед запуском pump нужно поставить python 2.4. Не знаю, может быть, последняя версия подойдет, я не проверял. Просто поставил 2.4, а потом снес. Причины изложены ниже.

Запускается pump просто:

$ pump make -j40 CC="distcc gcc"

-j указывает количество одновременно компилируемых файлов. Понятно, что на машине с одним процессором, -j40 выглядит странно, хотя и работает. Я пробовал -j8, имнно такое число выдает distcc -j,- никакой разницы.

В качестве примера я компилировал все тот же vim 7.2. Хорошие новости состоят в том, что pump заработал, запустил include server, и компиляция пошла довольно бойко. Плохие новости заключаются в том, что pump под конец сломался. Вот что я получил:

distcc[26164] ERROR: compile term.c on 192.168.0.180,cpp,lzo failed
distcc[26164] (dcc_build_somewhere) Warning: remote compilation of 'term.c' failed, retrying locally
distcc[26164] Warning: failed to distribute term.c to 192.168.0.180,cpp,lzo, running locally instead
ui.c: In function ‘fill_input_buf’:
ui.c:1823: warning: ignoring return value of ‘dup’, declared with attribute warn_unused_result
distcc gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -o objects/undo.o undo.c
distcc[26164] (dcc_please_send_email_after_investigation) Warning: remote compilation of 'term.c' failed, retried locally and got a different result.
distcc[26164] (dcc_note_discrepancy) Warning: now using plain distcc, possibly due to inconsistent file system changes during build
distcc gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -o objects/window.o window.c
distcc gcc -c -I. -Iproto -DHAVE_CONFIG_H -g -O2 -o objects/netbeans.o netbeans.c

__________Warning: 1 pump-mode compilation(s) failed on server, but succeeded locally.
__________Distcc-pump was demoted to plain mode. See the Distcc Discrepancy Symptoms section in the include_server(1) man page.

Ближе к завершению процесса один из файлов не скомпилировался на сервере, поэтому distcc переключился в обычный режим. Я пробовал выключить упаковку инклюдов (убрать параметр lzo), но это проблему не решило. Копать глубже надо, наверное, отсюда, но желания особого нет.

Еще одна особенность режима pump, которая мне не понравилась, это то, что вся компиляция происходит на сервере, а localhost только разбирает инклюды и отсылает их. В общем, время компиляции оказалось хуже, чем просто distcc без режима pump, чуть хуже того, что давала компиляция только на сервере.

Резюмируя, можно сказать, что pump пока сыроват, и использовать его имеет смысл только при наличии нескольких серверов.

Установка distcc 3.1-1 (клиент)

В одном из предыдущих постов описана установка серверной части distcc, чтобы он использовал TCP, а не SSH. Здесь речь пойдет о настройке клиентов.

На клиентской машине меняем /etc/distcc/hosts или ~/.distcc/hosts:

$ gksudo gedit /etc/distcc/hosts

Добавляем адрес нашего сервера и localhost:

#127.0.0.1
localhost
192.168.0.180

Сохраняем, проверяем:

$ distcc --show-hosts
localhost
192.168.0.180

Замечу, что адрес 127.0.0.1 использовать не стоит, хотя потеря будет всего в несколько секунд:
distcc[4232] ERROR: nonblocking connect to 127.0.0.1:3632 failed: Connection refused
distcc[4232] Warning: failed to distribute buffer.c to 127.0.0.1, running locally instead

Если к хосту подконнектиться не удалось с ошибкой Connection refused, distcc, больше не будет пытаться его использовать. Это означает, что и localhost использоваться для компиляции не будет.

Стоит сказать, что серверов, как и клиентов может быть несколько. Если серверов много, то имеет смысл localhost вообще не использовать на клиенте. Также, быстрые серверы надо указывать в начале списка.

Как с его помощью собирать:

$ ./configure
$ make -j40 CC="distcc gcc"

Статистика: компилировал vim 7.2.
Make без DistCC- 2 мин 17 сек.
С использованием distcc, только на сервере, и с ошибкой в 127.0.0.1- 1 мин 54 сек.
С использованием distcc, только на сервере- 1 мин 51 сек.
С использованием distcc, на localhost и сервере- 1 мин 10 сек.

Процесс распределенной компиляции можно наблюдать в distccmon-gnome (устанавливается отдельно):

$ sudo apt-get install distccmon-gnome

Вот его окно:

Настройка Samba на домашнем сервере

Ubuntu Server поставляется с самбой, так что ее надо только настроить.

Создаем директорию, которую чиатать могут все, а вот записывать в нее сможет только суперпользователь:

$ sudo mkdir /home/public
$ sudo chmod 755 /home/public

А в home/public создаем директорию, в которую у всех есть полный доступ:

$ sudo mkdir /home/public/pictures
$ sudo chmod 777 /home/public/pictures

Добавляем нового пользователя samba:

$ sudo smbpasswd -a alex

Настройки расшаренных директорий хра$

$ sudo vim /etc/samba/smb.conf

Добавляем группу для директории нашего пользователя под закомментаренной группой [homes], расшариваем на чтение/запись только этому пользователю:

[alex]
comment = Alex Home Dir
writeable = yes
valid users = alex
path = /home/alex

Также указываем нашу public директорию, расшариваем ее на чтение и запись для всех:

[public]
comment = Public
writeable = yes
public = yes
path = /home/public

Рестартуем самбу:

$ sudo /etc/init.d/samba restart

Теперь для захода в свою директорию всегда запрашивается пароль, а в директорию public пароль не нужен. В public/pictures записывать и смотреть файлы может кто угодно.

Установка distcc 3.1-1 (сервер)

На прошлой работе я активно использовал IncrediBuild под Visual C++. Под линукс существует distcc. Как пишут, он работает с 89% эффективностью. Ну, я не то что бы решил проверить, насколько правдива реклама, просто хочется, чтобы комилировалось побыстрее. Поэтому и решил установить distcc на домашний сервер Ubuntu 9.04.

Собственно установка- простая. Надо скачать deb пакет distcc 3.1-1 и установить его, а затем- запустить сервер. Можно собирать из исходников, я не пробовал. Подробные инструкции по установке- здесь.

$ sudo dpkg -i distcc-server_3.1-1_i386.deb

Установщик пытается, помимо собственно установки, еще и запустить демона, но ему это не удается:

update-rc.d: warning: /etc/init.d/distcc missing LSB information
update-rc.d: see
* Starting distccd... distccd[2720] (main) ERROR: --allow option is now mandatory; you must specify which clients are allowed to connect distccd[2720] (dcc_exit) exit: code 101; self: 0.010000 user 0.000000 sys; children: 0.000000 user 0.000000 sys
[fail]
invoke-rc.d: initscript distcc, action "start" failed.

Как видно, возникло две проблемы. На первую, LSB, внимания обращать не стоит. Для решения второй надо просто добавить айпишники разрешенных хостов в clients.allow:

$ sudo vim /etc/distcc/clients.allow

Рестартуем distcc:

$ sudo invoke-rc.d distcc stop
$ sudo invoke-rc.d distcc start

Все, можно переходить к настройке клиента. Про это- в другом посте.

Установка пакетов deb на сервер

Также, как и на десктоп:

$ sudo apt-get install package
или
$ sudo dpkg -i package.deb

Как выключить сервер?

У меня к серверу не подключены ни монитор, ни клавиатура. Соответственно вопрос- как его выключить удаленно? Ответ:

sudo poweroff
или
sudo halt -p

-p говорит, что надо делать power-off, и, действительно, компьютер выключается. Очень удобно.

UPD: Ну а если настроен Wake On LAN, то надо делать

sudo halt