Симлинки в shared папках под VirtualBox

С некоторых пор в гостевой системе под VirtualBox в примонтированной shared-папке нельзя создать симлинк. Связано это с безопасностью и в какой-то версии такую возможность по-дефлоту выключили, но оставили параметр, которым можно это поведение исправить. Какую-то информацию по теме можно подчерпнуть из тикета #10085.
Собственно, далеко не всегда гостевая ОС отдаётся посторонним лицам, которые могут попытаться набезобразничать, иногда VirtualBox ставится для своих нужд, и иногда симлинки действительно нужны и именно в примонтированных папках.

Итак. По-умолчанию при попытке создать симлинк из гостевой ОС в консоли получаем что-то вроде:
$ ln -s some/path/to/dir
ln: creating symbolic link `some/path/to/dir': Read-only file system

хотя файловая система совсем не read-only.

Выполняем
$ VBoxManage setextradata <vm_name> VBoxInternal2/SharedFoldersEnableSymlinksCreate/<share_name> 1

в моём случае это
$ VBoxManage setextradata centos VBoxInternal2/SharedFoldersEnableSymlinksCreate/www 1

Дальше, чтобы убедиться, что настройки сохранились, выполняем
$ VBoxManage getextradata <vm_name> enumerate

и видим появившуюся новую строку с нашей папкой.

Теперь перезапускаем VirtualBox (простого ребута гостевой ОС недостаточно) и спокойно создаём символические ссылки на примонтированной файловой системе.
Если рестарт виртуалбокса не помогает, то можно перезапустить его модули, после этого изменения точно учтутся при старте виртуальной машины.


P.S. Попутно добавлю.
Если при настройке shared-папок в VirtualBox поставить галку на автомонтирование

то система при старте сама будет пытаться примонтировать эту папку (само собой при условии, что установлены vbox guest additions).
Скорее всего дефолтное расположение примонтированной папки не устроит, тогда достаточно просто добавить запись в fstab
<share_name>   /<path/to/dir>        vboxsf     defaults,gid=502,uid=500,dmode=775,fmode=755   0 0
(uid,gid,dmode,fmode можно поправить по вкусу, либо убрать нафиг)

Теперь папка будет в правильном месте. И не нужно писать никаких скриптов для монтирования этой папки и пихать их в автозагрузку...

Resize virtual box virtual-hard-disk-drive

Появилась как-то необходимость увеличить размер virtual-hdd для vitrualbox. На деле оказалось, что ничего сложного в этом нет:

- в virtual media manager в самом virtualbox'е выбирем копирование/клонирование для требующего ресайза "диска"
- hard drive type указываем VDI
- обязательно выбираем динамически расширяемый (или как в рускоязычной vbox это называется) диск, а не фиксированного размера
- в консоли идём в папку, где лежит файл нового "диска" (необязательный пункт)
- выполняем в консоли
   $ VBoxManage modifyhd --resize <new_size_in_MB> disk-name-file
например
   $ VBoxManage modifyhd --resize 10000 disk1,vdi

Всё.
Дальше "подключаем" свежескопированноотресайзенный "диск" на место старого и можем запускать виртуальную машину.

P.S. Само собой разделы на "диске" не изменились, и если требуется не создание нового раздела, а увеличение существующего, то придётся воспользоваться сторонним софтом, благо нет проблем скачать небольшой livecd-образ и загрузившись в виртуалке с него через тот же gparted отресайзить разделы.

DeaDBeeF и пауза при активации screensaver'а

Относительно недавно наткнулся на замечательный аудиоплеер под linux - DeaDBeeF.

First steps in mongoDB

Что такое MongoDB подробно описывать не стану. Упомяну лишь, что это NoSQL документо-ориентированная СУБД.
Вдруг появилась необходимость её использования. В качестве ОС - CentOS:

После обновления до Gnome 3.4 формы в Opera стали выглядеть странно

После обновления gnome до версии 3.4 input'ы и select'ы в "нестилизованных" формах в opera стали выглядеть довольно странно:

Причиной стала обновлённая Adwaita (используемая по-умолчанию theme) со своими стилями. В новых релизах оперы обещают эту проблему пофиксить.
Сейчас же проблема решается через выставление параметра "Dialog Toolkit" в единицу или в четыре. Т.е. открываем opera:config, в поиске вводим "Dialog Toolkit", выставляем требуемое значение, жмём "Save" и рестартуем оперу.

При значении "1" будет использоваться qt (в том числе и диалоги):

При значении "4" будет использоваться gtk

P.S. Решение подсмотрено здесь.

Update:
Opera обновилась до 11.64, но проблема не пропала. Зато после изменений "Dialog Toolkit" при значении, равном четырём, диалоги похожи на Win98, но при значении, равном двум, используется gtk и нормально отображаются формы на страницах.

Couchbase из исходников в arch linux

Появилась необходимость поставить couchbase, а так как под arch покетов нет, пришлось собирать из исходников.
Опишу сам процесс чего делал и чего получалось, есть моменты, которые лучше сразу сделать немного иначе, так что использовать статью как руководство получится только после полного прочтения. Итак, начнём.
$ wget http://packages.couchbase.com/releases/1.8.0/couchbase-server_src-1.8.0.tar.gz
$ tar xzf couchbase-server_src-1.8.0.tar.gz
$ cd couchbase-server_src

В папке уже лежит готовый Makefile, но путь для установки в нём прописан явно :(
Начал собирать (собственно собранное приложение сразу будет скопировано/установлено в указанную в makefile папку)
$ sudo make    # при сборке хочет много доступа, пришлось запускать из под sudo

Почти сразу посыпались ошибки об объявленных, но неиспользуемых переменных, при этом в первом месте ошибки использование переменной было внутри if'а, так что теоретически она могла и не использоваться, но просто убрать объявление переменной уже нельзя... Хорошо, в сообщении об ошибке есть намёк '-Werror=unused-but-set-variable', не помню уже как точно пишется, но как раз про объявленное и неиспользуемое. Так как использоваться результат сборки будет не на проде, сильно не заморачиваюсь и просто заменяю ключ на -Wno-error, чтоб warning'и оставались предупреждениями (а не ошибками).
$ sudo grep -Rl 'Werror' * | grep -Ei 'configure|makefile' | while read i; do sudo perl -i.bak -pe 's/-Werror/-Wno-error/g' $i; done

Сразу оговорюсь - постоянно сидеть под root'ом не люблю, а так как привилегий при сборке надо много, то и часть файлов уже доступны только root'у, поэтому дальше будет много sudo

Запускаю собираться дальше, вроде идёт нормально.
Отвалился при сборке memcached, пришлось memcached собирать отдельно. Он в соответствующей папке, так что
$ cd memcached
$ ./configure
$ make

Возможно, надо будет так же подправить -Werror на -Wno-error

Теперь обратно в couchbase-server_src и пробую дальше собрать. Теперь отваливается на том, что не может найти бинарники memcached. Ага, значит видит, что эта часть собрана и заново не начинает компилировать, но найти результат не может. Ну само собой, я же не указал --prefix при сборке memcached и он установился в саму систему, а не в ту папку, где его ищёт "сборщик" couchbase.
Дальше можно попробовать вычистить установленный memcached и собрать его с указанием правильного пути, либо... Я просто скопировал бинарник в папку, где его не мог найти "сборщик".

Опять запускаю sudo make
Теперь вываливается с ошибкой
"erlang not loading native code for module hipe_unified_loader: it was compiled..."
Немного погуглив и попробовав просто запустить erlang понимаю, что проблема в нём. Нахожу фразу "This was introduced in a change to the Erlang VM PKGBUILD for R14B04, which added the -enable-native-libs compile flag". Ясно, удаляю erlang, который поставился из репозитория, ставлю его из AUR. На всякий случай собрал пакет и с этим ключом и без него, установил тот, который был "с ключом".

Теперь наконец-то make доводит своё дело до конца. А я обращаю внимание, что couchbase собрался в /home/george/downloads/couchbase-server_src/install. Да, не самое удачное место для софта. Надо было, на самом деле, для начала попробовать просто скопировать содержимое этой папки куда-нибудь в /usr/share/couchbase и затем поправить все пути в конфигах... Но я (собрал же уже один раз) решил пересобрать всё предварительно изменив путь в makefile'е.

Увы, с ходу всё собираться не захотело и полезли новые ошибки :(
Ладно, решил ставить в /opt/. Распаковал исходники туда, указал в makefile путь /opt/couchbase, изменил -Werror на -Wno-error, запускаю
$ sudo make
Опять не собирается memcached. Не собирается и индивидуально из своей папки, вываливает ошибки типа
mv $(DEPDIR)/example_protocol_la-example_protocol.Tpo $(DEPDIR)/example_protocol_la-example_protocol.Plo
can't stat $(DEPDIR)/example_protocol_la-example_protocol.Tpo, no such file or directory
(пишу по памяти, так что могут быть не точности, но смысл должен быть понятен).

В m4 я не силён, не знаю почему .Tpo переименовываются в .Plo ещё до выполнения этой строчки, так что решаю простым добавлением конструкции
if test ! -f <файл>.Tpo; then cp <файл>.Plo <файл>.Tpo; else :; fi
в memcached/Makefile
Хорошо, что в vim'е макросы записывать просто и добавить такую конструкцию пришлось пару раз, во все остальные места vim добавил её сам.

Пересобирал ещё раз и просто в Makefile заменил строку `am__mv = mv -f` на `am__mv = cp -f`, чтобы он не ругался на отсутствующие файлы...
После этого memcached собрался нормально.
опять sudo make в couchbase-server_src и ошибка
"configure: error: `CPPFLAGS' was not set in the previous run"
Хм. Вижу в самом конце вывода "make[1]: Leaving directory `/opt/libvbucket'"
$ cd libvbucket
$ sudo ./configure --prefix=/opt/couchbase --disable-static --enable-shared --without-docs --no-create --no-recursion       # доп. ключи - это из последнего, что было в stdout перед ошибкой
$ sudo make
$ cd ../
$ sudo make

Дальше аналогичные ошибки для memcachetest и moxi. Решаются таким же образом, ключи для configure так же вываливаются в stdout перед сообщением об ошибке.

couchbase собрался.

UPD: Собрался, но запускаться отказался :( . Буду думать дальше...

OpenSUSE 11.4 и Samba

После обновления openSUSE до 11.4 столкнулся с неприятной особенностью - samba ни в какую не хочет работать. Настраивал и правкой конфига, и тыканием мышкой в ясте - самба настроена, всё указано правильно, но не работает. Просто не запускается ни в какую и всё тут. Запустив в interactive режиме получил ругань, что permission denied при попытке открыть secrets.tdb и passdb.tdb. И это при том, что самбу запускал из под рута и при debug level 3+ (третий и выше) она честно писала, что работает от имени uid=0.
Оказалось, всё дело в apparmor. Видимо, разработчики/мейнтейнеры openSUSE где-то недоглядели и по дефолтным профилям apparmor ограничивал доступ самбы к этим файлам. По-быстрому объяснить apparmor'у, что к этим файлам обращаться можно, не получилось, поэтому просто снёс его профили, касающиеся самбы. По-дефолту лежат здесь - /etc/apparmor/profiles/extras/.