Днес исках да си инсталирам една игра 😀 но ми трябваха малко Windows библиотеки. Реших да ги попълня с winetricks и когато стартирах скрипта получих следното ведро съобщение –


$ ./winetricks
 ------------------------------------------------------
 wineserver not found!
 ------------------------------------------------------

Доста забавна ситуация и същевременно крайно очевидна. Winetricks не намира wineserver binary файлът.  Общо взето нормално понеже ползвам x64 Debian Linux и пакетите който ползвам не са от официалния източник. Решението е елементарно в 2 стъпки

1. Намираме пътя на wineserver


$ locate wineserver
/usr/lib32/wine-unstable/wineserver
/usr/share/man/de.UTF-8/man1/wineserver.1.gz
/usr/share/man/fr.UTF-8/man1/wineserver.1.gz
/usr/share/man/man1/wineserver.1.gz

И създаваме символична врзка към /usr/local/bin/wineserver където въпросния скрипт търси файлът по подразбиране но в моя случай е /usr/lib32/wine-unstable/wineserver


#ln -s /usr/lib32/wine-unstable/wineserver /usr/local/bin/wineserver

В последните няколко дни водим разговор с един приятел сис админ тип яйцето или кокошката – Debian vs Slackware. Както обикновено когато дебатираме с него няма победител аз си обичам моята религия той неговата, и двамата имаме достатъчно причини да го правим. Но покрай всичките бръщолевци ми отново се запитах защо. Защо използвам Debian на сървъри десктоп и декстоп машини ( дори си бях пуснал chroot на android-а ми). Тук се сещам и за твъдението на един мой бивш шеф:

Знаеш ли кой е най добрият Linux?

– Този който си успял да си инсталираш пръв.

В интерес на истината Slackware 9 мисля че беше първата ми дистрибуция която сам си инсталирах 😀 Но нещата се променят. Та ето някой от моите причини защо Debian:

1. Защото се поддържа лесно – зависимостите между пакетите. Дам това е отявления минус на slackware или плюс зависи как е погледнато. Зависимостите между пакетите е „екстра“ която улеснява кардинално инсталацията поддръжката и менаджирaнаето на една система. Когато искам да си инсталирам php не е необходимо да знам дали имам и останалите библиотеки необходими за да запали нормално. Спомням си един случай преди няколко години когато инсталирах на един web server и всички мъки докато попълня зависимостите да се компилират необходимите модули по php-то. Дам от друга страна получаваш двоичен пакет компилиран с някакви опции които може да не работят правилно за твоя случай или пък просто да липсва необходими опции. Еми за тия случай си има apt-get source дърпаш си сорска от който е билднат пакета плюс всички кръпки които са сложени. Модификации и модерации винаги са възможни по личен вкус и усмотрение.

2. Защото има netinstall cd – минимален image с основни пакети. Малко се чудя това колко би било полезно за нови потребители но за всеки системен администратор минималната инсталация си е преимущество. Инсталират се по малко пакети по малко сервизи. Изгражда се системата почти от 0. Така имаш сигурността че ще работи точно по начина по които очакваш – ни по малко ни повече. Преди няколко дни исках да сваля slackware cd1 за x64 система и бях неприятно изненадан че съществува само dvd вариант на х64 варианта им. Само за х86 има опция да се свали cd1 досататъчно за минимална инсталация. Не че е болка за умиране по време на инсталацията ще се изберат необходимите пакети но все пак цяло dvd за скелета на един сървър 😀 WTF??? Debian netinstall image ти предлага възможността пак за избор на какви допълнителни пакети да се издърпат от интернет като позитива е, че ще бъдат последната версия в огледалото stable/testing/unstable.

3. Защото има супер елементарен инсталатор – конзолата не е плашеща. Тук нещата са малко 50/50 защото и Slackware също е с изключително лесен инсталатор с единственото изключение което е ключово разделянето на диска се налага да се напишат малко команди в конзолата което е плашещо за някои потребители. fdisck или cfdisk не са толкова страшни но факта че не е вградено в инсталатора само по себе си е недостатък. Веднъж създаден дяла после се форматира от инсталатора но до тогава трябва да си почел малко. При Debian нещата са улеснени в това отношение по подразбиране инсталатора ти помага за това , но ако държиш да процеса да го контролираш по от близо винаги можеш да извикаш shell-а.

4. Защото debian екипа са отворени към странни идеи. Хммм някой слакър тука би ми се изсмял грубо, че такива изрудщини като кръстосан linux с BSD ядро не е необходим, но пък защо не. Хората преди са се смеели и на твърдението че, земята е кръгла. 😀 Ако не се лъжа Debian работи на  най- голяма колекция от хардуер 😉

5. По подразбиране не е с KDE – много мразим KDE. А както е всеизвестно Патрик е голям радетел на KDE и винаги това е била подразбиращата се графична среда в Slack-а. Още при първата ми среща с KDE разбрах че това не е моя тип GUI освен всичко друго много ми напомняше и за Windows

http://www.youtube.com/watch?v=10k3JwZUXlc

Да движиш някакъв проект в който се програмира активно без контрол над версиите в днешно време е пълно безумие. Като цяло има множество опции bazaar , mercurial , git , svn . Така тука ако ще очаквате да обяснявам кой контрол над версиите е по добър и защо няма да е. При нас използваме git. Причини много – лесно се настройва, много е гъвкав, написан е от Линус Торвалдс за да обслужва Linux Kernel версиите, последното са поне 2 причини 😉 . Днес ми се наложи да създам ново хранилище, че се започна нов проект. Реално съм създавал малко хранилища и то преди много време когато са ни трябвали и съм забравил тънките моменто по това. Създавам хранилището блъснах няколко файла за първото съхранение всичко мина точно. Самата настройка на хранилището беше стандартна:


git init
echo "Short project's description" > .git/description
git config --global user.name "Your Name"
git config --global user.email "[email protected]"
git commit -a
touch .git/git-daemon-export-ok

В общи линии нищо което да не е наред. След това реших да тествам от отдалечена машина да съхраня съдържание и при опита да го push-на ми изгърмя с грозното съобщение:

Pushing to git://gitHost/project
remote: error: refusing to update checked out branch: refs/heads/master
remote: error: By default, updating the current branch in a non-bare repository
remote: error: is denied, because it will make the index and work tree inconsistent
remote: error: with what you pushed, and will require ‘git reset –hard’ to match
remote: error: the work tree to HEAD.
remote: error:
remote: error: You can set ‘receive.denyCurrentBranch’ configuration variable to
remote: error: ‘ignore’ or ‘warn’ in the remote repository to allow pushing into
remote: error: its current branch; however, this is not recommended unless you
remote: error: arranged to update its work tree to match what you pushed in some
remote: error: other way.
remote: error:
remote: error: To squelch this message and still keep the default behaviour, set
remote: error: ‘receive.denyCurrentBranch’ configuration variable to ‘refuse’.
To git://gitHost/project
! [remote rejected] master -> master (branch is currently checked out)
error: failed to push some refs to ‘git://gitHost/project’

Така очевидно се опитвам да комитвам в главното дърво на проекта и софтуера вежливо ме режи. Като цяло нямам никакво намерение да правя допълнителен бранч понеже хората които участват по проектите са си ясни и ред други причини. Тука идва момента да отбележа че съм дефинирал много некадърно заглавието но това е друг момент. Като цяло решението на проблема е тривиално в .git/config на проекта ви трябва да добавите следната директива:


[receive]
denyCurrentBranch = false

След това всичко си идва на мястото.

http://www.youtube.com/watch?v=16bRiH5zfOY

Packet Tracer

Image via Wikipedia

Днес ми се наложи да демонстрирам една симулация през Cisco Packet Tracer на машина на която не беше инсталиран. В общи линии малоумщината е, че стимулатора на Cisco е за x86 машини а при мен машината беше x64. При опит за инсталация умира с грозното съобщение

Attempting to install package now
dpkg: error processing PacketTracer-5.3_3.i386.deb (–install):
package architecture (i386) does not match system (amd64)
Errors were encountered while processing:
PacketTracer-5.3_3.i386.deb

Общо взето всичко е очевидно Debian-ския пакет не иска да се инсталира защото е за друга архитектура. От тук нататък проблема е ясен dpkg + форсирано инсталиране за да байпаснем грешката за различна платформа. Bin-ския файл на инсталатора реално е само разархивиращ се архив който се разархивира в /tmp/selfextract.XXXXX папка където XXXXX е произволен низ. В тази директория се намира .deb файлът на Packet Tracer-a. Инсталацията се извършва с командата

dpkg -i --force-all /tmp/selfextract.XXXXX/PacketTracer-5.3_3.i386.deb

Естествено с root права.

Enhanced by Zemanta

Вчера след обновяване на версията на mysql, server-ът ми започна да ми крещи, че има табличка, която не е била затворена чисто и има нужда от поправка и прочие. Блах, коя ще е тая таблица, все пак са ми около 30-тина на тоя сървър. Единият вариант е да видите в log-овете какво пише по въпроса и да пуснете поправка на съответната таблица или другият вариант – далеч по-добрият – е да пуснете поправка, проверка и оптимизиране на всички таблици. За тази цел ще използвам mysqlcheck инструмента. Общо взето вариантите в случая са като и двете коменди са синонимни една на друга:


mysqlcheck -Aor -u root -p

mysqlcheck -u root -p --auto-repair --check --optimize --all-databases

Общо взето, която и от двете команди да използвате, ефектът ще е еднакъв – ароматична поправка, проверка  и оптимизация на всички таблици. След като напишете която и да е от двете команди, ще бъдете попитани за root паролата на mysql server-a ви.