Voimme helposti tappaa tietyn käyttäjän kaikki mysql-pyynnöt tyylikkäällä:

select concat('KILL ',id,';') from information_schema.processlist where user='user123';

Korvaamme käyttäjän123 haluamallasi käyttäjällä ja ajamme mysql: ssä, ja kaikki on OK 🙂

Ostimme Fantastico Deluxe -asentajan viime viikolla, mikä on mielestäni nöyrimpiä CPanel-palvelimille. Asensimme sen, testasimme sen ja kaikki meni sujuvasti. Tänään asiakas ilmoitti Wordpress-asennuksen koodauksen ongelmasta. Tarkastelin asioita ja valotin heti ongelman, tietokannat koodattiin oletuksena Latin1 UTF8: n sijasta, kuten oli tarkoitus. Se on vielä hauskempaa, että phpmyadminissä on kirjoitettu, että UTF8: ta käytetään oletuksena, draama. Päätin katsoa Fantastico-tiedostoja nähdäkseni, oliko jossain, missä voisin tarjota oletusarvoiset tietokantaasetukset ensi silmäyksellä, en nähnyt mitään. Sitten jotain kiirehti minua katsomaan, mikä on my.conf-tiedostossa ja mitä nähdä, että kokoonpanossa ei ollut vastaavia asetuksia ja kaikki menee oletusasetuksiin. Mysql-palvelin on kovakoodi UTF8: n käyttämiseen, jos sitä ei ole määritetty muiden asetusten kanssa ja Fantastico on ilmeisesti Latin1: n kanssa. ( mikä on aika tyhmä päätös). Kuten aina, ratkaisu on triviaalinen 2 järjestys c [mysqld] osa tehdä UTF8: sta oletuskoodauksen ja kaikki nukkuu 🙂

merkistön-palvelin = utf8
lajittelu-palvelin = utf8_general_ci

Minulla ei ole aavistustakaan, miksi kaipaan näitä asetuksia, koska pelasin tehdäkseni muutaman “hieno” mysql-asetukset.

Parantaa Zemanta

Se ilmestyi muutama päivä sitten Xampp 1.8.0 eilen päivityksen jälkeen versiosta 1.7.7 Minulla oli melko mielenkiintoinen ongelma. Phpmyadmin-а не ми се отваряше и изгърмяваше със 403

Access forbidden!


New XAMPP security concept:

Access to the requested object is only available from the local network.

This setting can be configured in the filehttpd-xampp.conf”.

Веднага отворих httpd-xampp.conf който при мен се намира в /opt/lampp/etc/extra/, на пръв поглед всичко изглеждаше наред. Правилата за локалната мрежа бяха наред. Отделно че отварях от localhost. mitä vittuu ??? Погледнах log-а гледам че достъпа ми е отрязан от конфигуацията. Тука вече нещата ме ахнаха и честно казано донякъде малко на късмет открих проблема. След като преглеждах httpd.conf-а видях в Allow/Deny клаузите един последен ред Require all granted. О да еврика. Това е новия контролен механизъм който влезе в apache 2.4.x. Se antaa pääsyn tai estää pääsyn kaikille vaadituille, se yleensä jäljittelee Salli / estä -toimintoa :). За да поправим проблема добавяме Require all granted в директивите за папката /opt/lampp/phpmyadmin. Muutosten jälkeen se näyttää minusta

<hakemisto “/opt / lampp / phpmyadmin”>
AllowOverride AuthConfig Limit
Tilaa sallia,kieltää
Salli kaikista
Require all granted
</hakemisto>

 

Viangi voi kokeilla muita villit, esimerkiksi nimeämällä phpmyadmin-kansio jollekin muulle ja tekemällä aliaksen ei. Mutta se on ruma ja ei kovin merkityksellinen 🙂

p.s Minulta kysyttiin, miksi käytän XAMPP: tä eikä kaikkien komponenttien puhdasta asennusta, koska Debian synnytti heille – vastaus on hyvin hyvin yksinkertainen – LAISKUUS. Olen liian laiska kirjoittamaan muutama komento koskettamaan sitten conf -ani ja niin edelleen. Koko paketin lataaminen, purkaminen ja polttaminen on paljon helpompaa

Parantaa Zemanta

Image representing MySQL as depicted in CrunchBase

Jokin aika sitten kirjoitin MySQL Koko teksti Haku 🙂 Minulla oli tänään erittäin mielenkiintoinen kokemus yhdestä pyynnöstä. Yleensä kysely etsii tuloksia, jotka puuttuvat toisesta taulukosta. Yksi perusvalinta ja yksi alavalinta kyselyn WHERE-osassa. Yleensä luuranko on

SELECT DISTINCT (
`field`
)
FROM `table1`
WHERE `someID` =44
AND `firsTextField` NOT
IN (

SELECT DISTINCT (
`secondTextField`
)
FROM `table2`
WHERE `otherID` =44
)

Periaatteessa yksinkertainen kysely. Kirjoitin sen 30 sec Suoritan sen ja kone silmukoi. Pitkän ja kärsivällisen odottamiseni puolesta tai tarkemmin ~ 43 sekuntia . Spatin tuloksen lol . Pffff hulluhuone. Sisään koneeseen katsellen, että suoritin on normaalisti ladattu melkein tyhjäkäynnissä. Shokki ja kauhu. Suoritan kyselyn uudelleen sama tulos. Vittu WTF. Suoritan selittää kyselyn ja kaikki paistaa – toinen kenttä secondTextField on vain kokotekstihaku ilman hakemistoa, ja siellä levy on vaatimaton, noin 35 kt viivoja. Kuka lukea – kokotekstihaku ei ole hakemisto. Ongelma poistuu nopeasti

ALTER TABLE `links` ADD INDEX ( `linkUrlID` ) 

Ja asiat menivät paikoilleen Query vei 0.0005 sekuntia 😀

Ole varovainen indeksien laatimisessa, kyselyn nopeus riippuu sinusta vähän.

s.s Yleisesti ottaen olen syyllinen yllä olevasta tilanteesta paitsi siksi, että siitä puuttuu hakemisto, vaan koska siinä ei käytetä kokotekstin hakumenetelmää 😀

Parantaa 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 ви.