Amióta Snow leopard operációs rendszerre váltottam, másodszor történik meg velem az alábbi tortúra:

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ő.

Leer más »

Néhány perce Gentoo linuxra próbáltam java-t telepíteni, de a telepítés az alábbi figyelmeztetéssel, hibával leállt:

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ő.

Leer más »

A windows 7 megjelenésével egy rakat új billentyűkombinációval gazdagodtunk, ami valljuk be, olyan usereknek mint jómagam (akik annyira utálják az egeret (persze az új mighty-t már nem annyira)) rendkívül hasznos tud lenni.

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

Leer más »

Amennyiben Debian vagy Ubuntu rendszerű linux szerverünkön alapértelmezett (vagy alapértelmezetthez közeli) konfigurációval futtatjuk az Apache2 web szervert, nagy valószínűséggel a apache2-mpm-prefork wokert használjuk libapache2-mod-php5 -tel. Habár ez az alapértelemezett működés, nagy forgalom, illetve nagy, lassan futó scriptek esetében meggondolandó az apache2-mpm-worker használata, mivel a prefok modul memória igénye magas, illetve amiatt, hogy minden kérésrt egyetlen szál szolgál ki, a kiszolgálás sebessége nagymértékben lassulhat.

Nagy terhelésű szervereken ezek alapján mindenképpen érdemes a worker-t telepíteni, de ez felvet egy újabb problémát: a libapache2-mod-php5 csak a prefork-kal kompatibilis, a worker telepítése esetén a debian alapú rendszerek automatikusan eltávolítják azt.

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.

Leer más »

Mac OSX alatt VPN kapcsolat létrehozásához kattintsunk a System Preferences ikonra , majd a “Network” ikonra. .

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

Leer más »

Még az elején szögezzük le: A Dashboard jó dolog. A Dashboard hasznos dolog. A Dashboard szép dolog.

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…

Sok Mac felhasználó tette már fel nekem a kérdést, hogy osx alatt a root felhasználót hogyan lehet elérni.

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.

MySQL adatbáziskezelő szerver esetén lehetőségünk van replikikációra, azaz az adatokst módosító (beszúrás, update, törlés, stb.) szinte azonnali továbbítására kerülnek egy távoli szerverre is, így az adatokon végzett módosítások ott is végrehajtásra kerülnek.

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:

Leer más »

A Symantec (Norton) Antivirus illetve Internet Security termékek eltávolítása során – ha a telepítéskor azt beállítottuk – szükségünk lehet egy adminisztrátori jelszó megadására, amely megakadályozza a véletlen , vagy szándékos károkozás céljából történő eltávolítást.

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.

Windows (IIS / Apache) alatt futtatott php 5.x alatt, ha exec függvényt próbálunk hívni, könnyen az alábbi hiba (figyelmeztetés) fogadhat minket:

"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ó