Minden különösebb előjel nélkül kb. 50%-nél kikacsol a macbookom. (2009 év eleji ALU book). Ez után az akkumulátor menüben megjelenik a service battery felirat, ara buzdítva, hogy 1.) 40.000Ft körüli összegért vásároljak új akkumulátort 2.) küzdjek a garanciális szervizzel.

Ez után mindkét alkalommal az következett, hogy az akkumulátor lemerül 0%-ig (0:00 a hátralévő idő), majd miután már több mint 5 perce nulla perc van hátra, visszaugrik 50% környékére, és utána még szokatlan hosszú ideig bírja. Ez után lehet hogy eltűnik a service battery felirat, de ha el is tűnik, egészen biztosan újra meg fog jelenni.

Próbálkozhatunk SMC resettel, vagy egyfajta kalibrációs metódussal is, amit az apple ajánl a http://support.apple.com/kb/HT1490 cikkben. Az alábbiakban leírom magyarul, hogy mi a teendő.

Az SMC reset elvégzéséhez az alábbiak a teendők:

Kapcsoljuk ki teljesen a macbookot, távolítsuk el a Magsafe hálózati adapter csatlakozóját, majd távolítsuk el az akkumulátort is. Ebben az állapotban nyomjuk le, és tartsuk lenyomva a macbook bekapcsológombját, majd helyezzük vissza az akkumulátort és a töltő csatlakozóját.

A akkumulátor kalibrálásának lépései:

1. Csatlakoztassuk a Macbookhoz a Magsafe töltő csatlakozóját, és várjuk meg amíg a készülék teljesen feltöltődik. A teljesen feltöltött géphez csatlakoztatott Magsafe töltőn a LED zöld fénnyel világít.
2. Hagyjuk a töltőt teljesen feltöltött állapotban bekapcsolva és a töltőre csatlakoztatva két órán keresztül. Ez idő alatt használhatjuk a számítógépet.
3. Továbbra is bekapcsolva hagyva a gépet, távolítsuk el a Magsafe töltő csatlakozóját, és hagyjuk hogy a készülék lemerüljön. Ügyeljünk arra, hogy a Macbook az akkumulátor üzemmód miatt ne kerüljön alvó állapotba. Célszerű a gépet ezidő alatt használni.
4. Amikor az alacsony akkumulátorszint üzenet megjelenik, mentsük el a megnyitott munkánkat, majd várjuk meg amíg az akkumulátor annyira lemerül, hogy a gép alvó állapotba kerül.
5. Amikor a gép alvó állapotba kerül a hálózati töltő csatlakoztatása nélkül hagyjuk a Macbookot alvó állapotban öt órán keresztül.
6. Az öt óra leteltével a Macbookhoz újra csatlakoztatni kell a töltőt, és teljesen feltölteni. Ezidő alatt a számítógép újra használható.

Ezzel megtörténik az akkumulátor kalibrálása.

dev-java/sun-jdk-1.6.0.18-r1 (masked by: dlj-1.1 license(s), ~x86 keyword)

Az alábbi postban bemutatom, hogy hogyan telepíthető a java csomag, illetve hasonló esetben (licenc elfogadás) mi a teendő.

A pontos hibaüzenet tehát ez:

!!! All ebuilds that could satisfy “dev-java/sun-jdk” have been masked.
!!! One of the following masked packages is required to complete your request:
- dev-java/sun-jdk-1.6.0.18-r1 (masked by: dlj-1.1 license(s), ~x86 keyword)
A copy of the ‘dlj-1.1′ license is located at ‘/usr/portage/licenses/dlj-1.1′.

- dev-java/sun-jdk-1.6.0.18 (masked by: dlj-1.1 license(s), ~x86 keyword)
- dev-java/sun-jdk-1.6.0.17 (masked by: dlj-1.1 license(s))
- dev-java/sun-jdk-1.5.0.22 (masked by: dlj-1.1 license(s))

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

A megoldás, pedig az, hogy a “djl-1.1″ licencet el kell fogadni. Ezt az alábbi módok egyikével tudjuk megvalósítani:

1. Minden licenc automatikus elfogadásához írjuk be az alábbi sort az /etc/make.conf fájlba:

ACCEPT_LICENSE=”*”

2. Ha csak egy vagy több licencet szeretnél elfogadni, finomíthatod így:

ACCEPT_LICENSE=”DJL-1.1″

3. Ha egy adott licencet csak egy csomag telepítéséhez akarz elfogadni, akkor készíts egy /etc/portage/package.license fájlt. (ha van, fűzd hozzá az alábbiakat):

dev-java/sun-jdk dlj-1.1

A SUN Java környezet ezután emerge dev-java/sun-jdk paranccsal telepíthető.

Ebben a postban megpróbálok bemutatni néhányat ezekből a billentyűkombinációkból:

• Windows + fel nyíl: Az aktuális ablak méretének maximalizálása, teljes méretre állítása. Egérrel úgy is teljes méretűvé állíthatunk egy ablakot, hogy az ablakot megfogjuk, és a képernyő tetejére húzzuk. Amikor az egérmutató eléri a képernyő szélét, egy animáció jelzi, hogy az ablak elengedése esetén az teljes méretűvé válik.
• Windows + le nyíl: Amennyiben az aktív ablak maximalizált, újra normál méretűvé válik, amennyiben normál méretű, ikon állapotban a tálcára kerül. Teljes méretű ablakot úgy is visszaállíthatunk normál méretűvé, hogy az egérmutatóval megfogjuk a teljes méretű ablakot, és lefelé húzzuk.
• Windows + bal nyíl: Az aktív ablak rögzítése a képernyő bal széléhez. Az ablak a képernyő teljes magasságát el fogja foglalni, szélessége pedig a képernyő ötven százaléka lesz. Hasznos lehet például, ha két ablak tartalmát akarjuk összehasonlítani, ilyenkor az egyik ablakot balra, a másikat pedig jobbra rendezhetjük. Ezt a viselkedést úgy is előidézhetjük, hogy az ablakot megfogjuk, és egy határozott mozdulattal a képernyő bal oldalához húzzuk. Amikor az egérmutató eléri a képernyő szélét, egy animáció fogja jelezni, hogy az egérmutató elengedésével rögzül az ablak.
• Windows + Home gomb: Minden ablak kisméretű lesz, kivéve az aktuális.
• Windows  + P: “Projection menu”: Elsősorban laptopon van értelme, többszöri megnyomásával válthatunk a video kimenetek között (Beépített kijelző, kijelző csatlakozó, mindkettő).
• ALT + F4: Aktuális ablak bezárása.
• ALT + TAB: Váltás az előző aktív ablakra (A tab többszöri megnyomásával az alt felengedése nélkül többet is léphetünk az aktív ablakok között. Ilyenkor a képernyő közepén megjelenik egy lista a futó programok ablakairól. Egy ablakra úgy válthatunk, hogy a tab billentyű többszöri megnyomásával kiválasztjuk az ablakot, és felengedjük az alt gombot. Alternatív megoldásként a képernyő közepén megjelenő ikonora is kattinthatunk.
• ALT + ESC: A futó programok aktív ablakai között válthatunk vele.
• WIN + TAB: Az ablakok között válthatunk vele 3D módban. A TAB többszöri megnyomására mindig egy újabb ablak kerül előtérbe, a WIN gomb felengedésével az előtérben lévő ablak válik aktívvá.
• CTRL + WIN + TAB: Az ablakok között 3D módban válthatunk, úgy hogy a kombináció lenyomása és felengedése után a 3D mód aktív marad. A kívánt ablakot az egérgörgővel választhatjuk ki, majd rákattintva aktiválható az ablak.
• WIN + T: A tálcán az ablakok előnézetének megtekintése. (A WIN gomb nyomvatartása mellett a T gomb többszöri megnyomásával mindíg a soron következő előnézet tekinthető meg.)
• WIN + M: Minden normál és teljes méretű ablak ikonként a tálcára kerül. Egérrel elérhető úgy is, hogy az egeret a tálca jobb szélén lévő függőleges sávra húzzuk. Az egeret a sávra tartva az ablakok teljesen átlátszóvá válnak, csak a körvonaluk látszik. A sávra kattintva minden ablak kisméretűvé válik.
• WIN + SHIFT  + M: Az előző kombináció visszavonása.
• WIN + D: Asztal megjelenítése.
• Aero Shake: Egér bűvésztrükk, ha egy aktív, normák méretű ablakot megfogunk a fejlécénél, és az egérrel határozottan megrázzuk, minden ablak kisméretűvé válik, kivéve az amit fogunk.

Ebben a leírásban bemutatom, hogy hogyan tudjuk a preforkot workerre cserélni, illetve a libapache2-mod-php5 helyett hogyan tudunk mod_fcgi-t üzembe helyezni.

Apache2 worker és mod_fcgid telepítés:

apt-get install apache2-mpm-worker libapache2-mod-fcgid

mod_fcgid engedélyezése:

sudo a2enmod fcgid

Szükséges php5  modulok telepítése

Bármilyen php 5 modul telepíthető a rendszerre, amely szükséges a scriptek megfelelű működéséhez, pl.:

apt-get install php5-cgi php5-curl php5-gd php5-ldap php5-mysql php5-mysqli php5-sqlite php5-xsl

Apache2 beállítások

A csomagok telepítése után az apache2 beállítása következik. A példa az apache2 default virtualhostján keresztül mutatja be a beállításokat,  de ezeknek a módosításokat minden virtualhostban el kell végezni.

Keressük meg a virtualhost gyökérkönyvtárára vonatkozó bejegyzést, és egészítsük ki így:

<Directory /var/www>
AddHandler fcgid-script .php
FCGIWrapper /usr/lib/cgi-bin/php5 .php
</Directory>

majd pedig minden “directory” bejegyésben engedélyezzük a CGI futtatást:

Options ExecCGI Indexes

A virtualhostok mentése után csupán egy apache2 újraindítás van hátra:

/etc/init.d/apache2 force-reload

és a forrás pedig:

Ezt a cikket az alábbi leírás alapján portoltam a saját rendszeremre és magyar nyelven:

http://ivan.gudangbaca.com/installing_apache2_and_php5_using_mod_fcgid

A megjelenő ablakban a bal oldali lista alján található “+” gomb segítségével adjunk hozzá egy új kapcsolatot.

A + gombra kattintva új kapcsolatot hozunk létre

A kapcsolat típusa legyen “VPN”, a VPN típusa a kapcsolat típusától függően választandó, IPSEC, VAGY PPTP, neve pedig tetszőlegesen megválasztható.

VPN kapcsolat létrehozása

A kapcsolat létrejötte után megadhatóak annak paraméterei:

VPN paraméterek megadása

A “Configuration” menü maradhat üresen, a “Server Address” menüpontba a távoli szerver IP címét vagy host nevét adjuk meg, az “Account Name” mezőbe pedig felhasználónevünket írjuk!

Az “Encryption” választómezőben a kapcsolat paramétereitől függően “Automatic”, “Maximum”, vagy “None” választható.

Az “Authentication Settings” gomb megnyomásával az azonosítás módja választható meg: Jelszó, RSA token, Kulcsfájl (Certificate), Kerberos azonosítás, vagy CryptoCard.

VPN hitelesítési beállítások

A Connect gomb megnyomásával a kapcsolat azonnal felépíthető, a “Show VPN status in Menu bar” kapcsoló bekapcsolásával pedig a menüsorra lehet VPN státusz ikont varázsolni, amivel a kapcsolatok gyorsan a “System Preferences” megnyitása nélkül menedzselhetőek.

Arra, amire kitalálták, tökéletesen megfelelő. Csak leütjük az F12 billentyűt (vagy a képernyő megfelelő sarkába vonszoljuk az egeret), és máris hasznos minialkalmazások hada lepi el a képernyőnket.

Abban az esetben, ha Macunk nincs bővében a az életető memóriának, mégis célszerű lehet megszabadulni a dashboard-tól. A minialkalmazások akkor is foglalják a memóriát, ha éppen nem látjuk őket, és a dashboard is a memóriában csücsül.

A kikapcsolásukhoz indítsunk el egy terminal-t (Applications/utilities), és adjuk ki az alábbi parancsot (Normál user-ként):

defaults write com.apple.dashboard mcx-disabled -boolean YES

A parancs hatására a dashboard a következő induláskor már nem fog futni. Ahhoz, hogy azonnal megszabaduljunk tőle, a dock újraindítására van szükség, ezt pedig megtehetjük az alábbi paranccsal (kicsit dúrva, de hat…):

killall Dock

Ha újra szeretnénk a Dashboard-ot használni, a

defaults write com.apple.dashboard mcx-disabled -boolean NO
killall Dock

parancs párossal újra élvezhetjük a minialkalmazásokkal tarkított desktopunkat…

A root felhasználó az UNIX jellegű rendszerekben az “Isten”, a korlátozások nélküli, bármire képes felhasználó. A bármire képes, itt szó szerint bármire képes… Kárt is tud tenni, és itt nincs meg a windowsos jó tündér (Biztos benne, hogy meg akarja nyomni a biztos benne gombot?). Ha törölni akarunk, töröl. Elhiszi hogy mi jobban tudjuk – akkor is ha nem.

Szóval, hogy kerítsük elő ezt a felhasználót? Az esetek többségében semmi szükség rá (de azért megmutatom, hogyan kell életre bírni)!

Rendelkezésünkre áll a sudo parancs, amely a paraméterként kapott parancsot rendszergazdai jogosultságokkal hajtja végre, és cserébe csak a saját jelszavunk érdekli.

Például, a 

sudo nano /etc/hostconfig

a nano /etc/hostconfig parancsot fogja rendszergazda módban végrehajtani (máshogy nem lenne jogosultságunk elmenteni a változtatásokat), és az aktuálisan bejelentkezett felhasználó jelszavát kell beírni neki. Természetesen a megemelt jogosultsági szint csak az adott munkafolyamatra (parancsra) érvényes, minden már korábban elindított, illetve sudo parancs használata nélkül kiadott parancsra az átlagos felhasználói jogosultságok az érvényesek.

Lehetőségünk van arra, hogy egy konzolt rendszergazdai módba helyezzünk, ehhez a 

sudo -s

és a saját jelszavunk megadása szükséges. Sikeres alkalmazása esetén visszakapjuk a parancsértelmező promtját, és kilépésig (vagy exit parancsig) minden parancsunk rendszergazda módban fog végrehajtódni.

A root felhasznákó engedélyezése

a legegyszerűbb mód a

sudo passwd root

parancs használata, amellyel beállíthatunk egy új jelszót a root felhasználónak, amellyel aztán be tudunk jelentkezni.

Konzolról a

su

parancs segítségével válthatunk rendszergazda módba.

A megoldás ugyan elég távol áll egy terhelés-eolsztásos clustertől (A master node-ot írni és olvasni is tudjuk, de a slave-et csak olvasni), de ettől haszna még bőven akad:

Egyszerű failover megoldásnak tekinthető: Ha a master szerver elhasal, az adatok gyakorlatilag real time ott vannak a slave-en, csak meg kell neki mondani, hogy Ő mostantól nem slave.

Ha túl sok, vagy túl nagy adatbázisaink vannak, akkor a mysqldump-os megoldás problémás lehet a nagy erőforrásigény, a hosszú mentési idő, és a még hosszabb visszaállítási idő miatt. Ilyen esetben célszerű az adatfájlok közvetlen mentése. Tekintettel arra, hogy a MySQL szerver működése során memóriába pufferel adatokat, ha egy futó MySQL szerver alól kimentjük az adatfájlokat, korántsem biztos hogy minden adat a fájlban lesz, illetve hogy az adatfájl egyáltalán használható lesz egy visszaállítás után. Kézenfekvő a megoldás: slave szerverre replikáljuk az adatokat, majd mentés előtt a slave szervert leállítjuk. Szolgáltatásunk működését ez nem befolyásolja, hisz a kliensek továbbra is a master szerverrel kommunikálnak, a master pedig a binlogban gyűjti, azokat az utasításokat, amelyeket a slave-nek végre kell hajtania, hogy újra az aktuális állapotot tükrözze. A leállított slave adatfájljait ezután gond nélkül menthetjük, majd a mentés végzetével a slave adatbázis szerver ujraindításával minden megy tovább.

A master – slave replikáció megvalósítása:

Tekintettel arra, hogy a replikáció TCP kapcsolaton keresztül megy, így ha a mysql szerverünk úgy van beállítva, hogy csak unix socketeket használjon, konfiguráljuk tcp/ip használatra (my.cnf bind-address    = 0.0.0.0), továbbá a tűzfalunkon engedélyezzük a master és slave szerverek közötti kommunikációt a 3306-os porton.

A replikáció működéséhez a “replication slave” jogosultság szükséges. Természetesen a jogosultságot úgy kell felvenni, hogy a slave szerver IP címéről, vagy hostjáról érkező felhasználónak is megfelelő jogosultsága legyen.

Példáinkban feltételezzük, hogy a master szerver IP címe: 192.168.1.100, a slave szerver IP címe pedig 192.168.1.200.

Az első feladatunk, hogy létrehozzunk egy felhasználót a master szerveren, amely rendelkezik a fennt említett “repliaction slave” jogosultsággal.

Csatlakozzunk a master MySQL szerverhez, és hozzuk létre a megfelelő jogosultságú felhasználót:

# mysql -u root -p
mysql> grant replication slave on *.* TO repl@"192.168.1.200" identified by 'jelszo';
mysql> quit

Bátrak, és az egyszerű utat kedvelők, természetesen phpMyAdmin segítségével összekattintgathatják a felhasználót.

Következő lépéskét konfiguráljuk a mysql szervert úgy, hogy a modosítást végrehajtó lekérdezésekről készítson ún. binlogot.
Nyissuk meg szövegszerkesztővel a mysql konfigurációs állományát (általában /etc/my.cnf vagy /etc/mysql/my.cnf), és a [mysqld] bejegyzés után ellenőrizzük az alábbi sorok meglétét, illetve ha szükséges, hozzuk létre őket:

log-bin=mysql-bin
server-id=1
binlog-ignore-db="mysql"

Ha módosítanunk kellett a konfigurációs állományon, indítsuk újra a MySQL szervert:
/etc/init.d/mysql restart

A replikáció elindításához mind a master, mind a slave adatbázisnak ugyanazokat az adatokat kell tartalmaznia, teljes mértékben meg kell egyzniük.

Ehhez zároljuk a master adatbázist:

flush tables with read lock

és a mysqldump parancs használatával mentsük el a master adatbázis adatait.

mysqldump --all-databases --lock-all-tables >dbdump.db

a dbdump.db-t juttassuk át a slave szerverre és adjuk hozzá a slave mysql szerverhez:

mysql -u root -p < dbdump.sql

Természetesen, ha nem az összes adatbázis replikálását tervezzük, akkor elegendő csak a replikálni kívánt adatbázisok szinkronba hozása, illetve ha nagyon nagyok az adatbázisok, vagy speciális karakterkódolásokat használunk, akkor az adatfájlok átvitelével is megoldhatjuk a kezdeti szinkronizálást. (Ehhez persze a master adatbázist le kell állítanunk!)

Miután a két adatbázis szinkronban van, meg kell tundunk a master adatbázis binlog pozícióját.

A master szerverre bejelentkezve adjuk ki a

show master status

parancsot.

A parancs kimenet valami ilyesmi lesz:

+------------------+--------------------------+------------------+
| File             | Position  | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+--------------------------+------------------+
| mysql-bin.000112 |        79 |              | mysql            |
+------------------+--------------------------+------------------+

1 row in set (0.00 sec)

Jegyezzük fel a File és a Position mezők értékét. NAGYON fontos, hogy a binlog azt az állapotot tükrözze, amelyet átvittünk a slave-re. Azaz, az adatok átmásolása után azonnal jegyezzük fel a binlog pozícióját, mielőtt bármilyen módosítást végző lekérdezsé lefutna.

Ezzel a master szerveren végzendő módosításokkal megvagyunk, nyissuk meg a slave szerver my.cnf állományát, és a mysqld bejegyzés alatt adjuk hozzá a következő sorokat:

server-id=2
master-host = [MASTER Szerver IP]
master-user = [REPLIKACIO USER]
master-password = [REPLIKACIO JELSZO]
master-port = 3306

A master szerver címe értelemszerű,példánkban 192.168.1.100, a master-user az a felhasználónév, aminek a replication slave jogosultságot megadtuk, a jelszó pedig amit a grant parancsban az identified by után írtunk.

Indítsuk újra a slave szervert, majd jelentkezzünk be, állítsuk be a master szerver binlog fájl nevét, és pozícióját.

# mysql -u root -p
mysql> CHANGE MASTER TO MASTER_LOG_FILE='[binlog fajl, korabban leirtuk]',
MASTER_LOG_POS=[binlog pos, korabban leirtuk];
mysql> START SLAVE;
mysql> SHOW SLAVE STATUS;

A binlog fájl, és a master log pos helyére azokat az értékeket írjuk, amelyeket a show master status parancs kimenetéből lejegyeztünk.

Ha minden sikerült, akkor a show slave status parancs kimenetében a Slave_Io_Status mező értékének Waiting for master to send event-nek kell lennie.

Amennyiben azt látjuk, hogy connecting, vagy egyéb más üzenetet, a syslogból, vagy a mysql log-ból tájékozódhatunk a hiba jellegéről. (többnyire jogosultság probléma).

Ha az eltávolítási jelszót elfelejtettük, az alábbi módszerrel megkerülhetjük a jelszókérési ablakot, így eltávolíthatjuk a szoftvereket:

Indítsuk el a regisztrációs adatbázis szerkesztőt. (Start menü -> futtatás -> gépeljük be a regedit parancsot és üssünk Entert. (lehetséges, hogy szükségünk lesz egy rendszergazdai jelszóra a futtatáshoz.)

A megjelenő ablakban navigáljunk el az alábbi elemhez a bal oldali fastruktúrában:

HKEY_LOCAL_MACHINE -> Software -> Intel -> LanDesk -> VirusProtect6 -> CurrentVersion -> AdministratorOnly -> Security

A jobb oldali ablakrészen keressünk egy “UseVPUninstallPassword” nevű, “REG_DWORD” típusú bejegyzést, majd kattintsunk kétszer a nevén.

A megjelenő ablakban állítsuk 0-ra az értékét, majd OK gomb megnyomásával és a regedit bezárásával lépjünk ki az alkalmazásból.

A Norton termékek ezek után a szokásos módon eltávolíthatóak.

"Warning: system() [function.system]: Unable to fork".

esetleg

"Warning: shell_exec() [function.shell-exec]: Unable to execute"

A probléma okozója az, hogy hiába van a php kódot futtató felhasználónak (általában IUSR_gépnév) jogosultsága a kérdéses állományt végrehajtani, a php exec() függvénye nem közvetlenül azt próbálja futtatni, hanem a cmd.exe-t, aminek paraméterben adja át a futtatni kívánt parancsot.

Így, a működéshez a cmd.exe-re is megfelelő jogosultságot kell adnunk. A cmd.exe elérési útvonala: %windir%\system32\cmd.exe (Általában c:\windows\system32\cmd.exe vagy c:\winnt\system32\cmd.exe)

A fájlon jobb klikk, tulajdonságok (properties)

cmd.exe tulajdonságai

Amennyiben az INTERNET GUEST ACCOUNT (IUSR_gépneve) nincs a listában, kattintsunk a hozzáadás(add gombra), és a mezőbe írjuk be az IUSR szöveget, majd nyomjuk meg a Névellenőrzés gombot. (Apache esetén válasszuk azt a felhasználót, amely nevében az apache folyamatok futnak.)

Fontos!!! Határozottan ellenjavallott több jogosultságot adni az IUSR felhasználónak, mint amennyi a képen látható