abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
včera 17:53 | Bezpečnostní upozornění

Google na svém blogu věnovaném počítačové bezpečnost informuje o nalezení "reálného" způsobu generování kolizí hašovací funkce SHA-1. Podrobnosti a zdrojové kódy budou zveřejněny do 90 dnů. Již dnes lze ale na stránce SHAttered nalézt 2 pdf soubory, jejichž obsah se liší a SHA-1 otisk je stejný (infografika).

Ladislav Hagara | Komentářů: 1
včera 17:51 | Nová verze

Vyšla nová verzia open source software na správu a automatizáciu cloudových datacentier Danube Cloud 2.4. Danube Cloud je riešenie postavené na SmartOS, ZFS, KVM a zónach. Obsahuje vlastnosti ako integrovaný monitoring, DNS manažment, zálohy, a samozrejme rozsiahlu dokumentáciu.

dano | Komentářů: 0
včera 17:46 | Pozvánky

V Plzni se 3. až 5. března 2017 uskuteční AIMTEChackathon. Je to akce pro vývojáře, grafiky, webdesignéry i veřejnost. Akci provází zajímavé přednášky IT odborníků. Více o programu a možnosti přihlášení na stránkách akce.

cuba | Komentářů: 0
včera 01:00 | Nová verze

Známý šifrovaný komunikátor Signal od verze 3.30.0 již nevyžaduje Google Play Services. Autoři tak po letech vyslyšeli volání komunity, která dala vzniknout Google-free forku LibreSignal (dnes již neudržovaný). Oficiální binárky jsou stále distribuované pouze přes Google Play, ale lze použít neoficiální F-Droid repozitář fdroid.eutopia.cz s nezávislými buildy Signalu nebo oficiální binárku stáhnout z Google Play i bez Google účtu

… více »
xm | Komentářů: 5
22.2. 23:14 | Nová verze

Po třech týdnech od vydání první RC verze byla vydána první stabilní verze 17.01.0 linuxové distribuce pro routery a vestavěné systémy LEDE (Linux Embedded Development Environment), forku linuxové distribuce OpenWrt. Přehled novinek v poznámkách k vydání. Dotazy v diskusním fóru.

Ladislav Hagara | Komentářů: 6
22.2. 17:28 | Bezpečnostní upozornění

Byly zveřejněny informace o bezpečnostní chybě CVE-2017-6074 v Linuxu zneužitelné k lokální eskalaci práv. Jde o chybu v podpoře DCCP (Datagram Congestion Control Protocol). Do linuxového jádra se dostala v říjnu 2005. V upstreamu byla opravena 17. února (commit). Bezpečnostní chyba byla nalezena pomocí nástroje syzkaller [Hacker News].

Ladislav Hagara | Komentářů: 11
22.2. 15:00 | Zajímavý software

Společnost Valve vydala novou beta verzi SteamVR. Z novinek lze zdůraznit oficiální podporu Linuxu. Další informace o podpoře této platformy pro vývoj virtuální reality v Linuxu v diskusním fóru. Hlášení chyb na GitHubu.

Ladislav Hagara | Komentářů: 0
22.2. 06:00 | Nová verze

Po necelém roce od vydání verze 0.67 byla vydána verze 0.68 populárního telnet a ssh klienta PuTTY. Podrobnosti v přehledu změn. Řešeny jsou také bezpečnostní chyby.

Ladislav Hagara | Komentářů: 0
21.2. 21:32 | Nasazení Linuxu

Canonical představuje nejnovější verzi chytré helmy DAQRI s Ubuntu pro rozšířenou realitu. K vidění bude příští týden v Barceloně na veletrhu Mobile World Congress 2017.

Ladislav Hagara | Komentářů: 0
21.2. 21:31 | Pozvánky

Pro zájemce o hlubší znalosti fungování operačních systémů připravila MFF UK nový předmět Pokročilé operační systémy, v rámci něhož se vystřídají přednášející nejen z řad pracovníků fakulty, ale dorazí také odborníci ze společností AVAST, Oracle, Red Hat a SUSE. Tento předmět volně navazuje na kurz Operační systémy ze zimního semestru, ale pokud máte praktické zkušenosti odjinud (například z přispívání do jádra Linuxu) a chcete si

… více »
Martin Děcký | Komentářů: 6
Jak se stavíte k trendu ztenčování přenosných zařízení (smartphony, notebooky)?
 (13%)
 (2%)
 (71%)
 (3%)
 (10%)
Celkem 691 hlasů
 Komentářů: 66, poslední 22.2. 18:57
    Rozcestník

    Dotaz: MySQL a záhadně propojené sloupce

    K. T. Schnikow avatar 2.6.2008 08:06 K. T. Schnikow | skóre: 24 | Chrást u Plzně
    MySQL a záhadně propojené sloupce
    Přečteno: 263×
    Mám tabulku a v ní se mi děje cosi, čemuž moc nerozumím.
    create table logins
    (
    	logId		int unsigned		not null primary key auto_increment,
    	userId		tinyint unsigned	not null, /* FK */
    	login		timestamp		not null,
    	logout		timestamp,
    	hostId		smallint unsigned	not null, /* FK */
    	expired		bit			not null default 1,
    	foreign key (userId) references users(userId) on delete cascade,
    	foreign key (hostId) references hosts(hostId) on delete cascade
    ) engine=innodb;
    V té tabulce když provedu změnu dvou buněk v jednom řádku, tak se v onom řádku změní buňky tři. Myslel jsem si, že chyba je někde v aplikaci, nebo uložené proceduře, protože jak je už z tohoto výpisu zřejmé, doba přihlášení a odhlášení je vždy stejná. Tak jsem poslední hodnotu, která ještě nebyla nastavována, upravil ručně.
    mysql> select * from logins;
    +-------+--------+---------------------+---------------------+--------+---------+
    | logId | userId | login               | logout              | hostId | expired |
    +-------+--------+---------------------+---------------------+--------+---------+
    |     1 |      3 | 2008-06-01 17:20:02 | 2008-06-01 17:20:02 |      1 |         |
    |     2 |      3 | 2008-06-01 17:21:25 | 2008-06-01 17:21:25 |      1 |         |
    |     3 |      1 | 2008-06-01 17:22:12 | 2008-06-01 17:22:12 |      1 |         |
    |     4 |      2 | 2008-06-01 17:26:12 | 0000-00-00 00:00:00 |      1 |       1 |
    +-------+--------+---------------------+---------------------+--------+---------+
    4 rows in set (0.00 sec)
    Spustil jsem samotný příkaz update zkopírovaný z uložené procedury.
    mysql> update logins set expired=0,logout=current_timestamp where logId=4;
    Query OK, 1 row affected (0.00 sec)
    Rows matched: 1  Changed: 1  Warnings: 0
    Výsledek mě dosti zarazil. Posuďte sami.
    mysql> select * from logins;
    +-------+--------+---------------------+---------------------+--------+---------+
    | logId | userId | login               | logout              | hostId | expired |
    +-------+--------+---------------------+---------------------+--------+---------+
    |     1 |      3 | 2008-06-01 17:20:02 | 2008-06-01 17:20:02 |      1 |         |
    |     2 |      3 | 2008-06-01 17:21:25 | 2008-06-01 17:21:25 |      1 |         |
    |     3 |      1 | 2008-06-01 17:22:12 | 2008-06-01 17:22:12 |      1 |         |
    |     4 |      2 | 2008-06-01 17:26:25 | 2008-06-01 17:26:25 |      1 |         |
    +-------+--------+---------------------+---------------------+--------+---------+
    4 rows in set (0.00 sec)
    Přestože nad tabulkou není nikde vytvářen žádný trigger a v příkazu update se při odhlášení nastavují jen sloupce expired a logout, změní se i hodnota ve sloupci login. Nedovedu si takové záhadné chování MySQL-serveru vysvětlit. Čím to může být, že při vkládání se sloupce chovají normálně a při úpravě se chovají, jakoby byly jen jeden?
    Co Bůh rozbil, člověk neopravuj!

    Řešení dotazu:


    Odpovědi

    2.6.2008 09:17 Filip Jirsák | skóre: 66 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: MySQL a záhadně propojené sloupce
    Zkusil bych si tu samou tabulku (bez FK) vytvořit na nějaké úplně čisté databázia porovnat, zda se to bude chovat stejně. Ať víte, kterým směrem pátrat – zda je to problém právě té jedné instance vaší databáze, nebo zda se tak chová MySQL vždy.
    Dalibor Smolík avatar 2.6.2008 09:35 Dalibor Smolík | skóre: 54 | blog: Postrehy_ze_zivota | 50°5'31.93"N,14°19'35.51"E
    Rozbalit Rozbalit vše Re: MySQL a záhadně propojené sloupce
    Zkusil jsem si takovou tabulku vytvořit, změny se projevují podobně (změna v obou polích při zadání změn jen v jednom z nich) - není to právě vlastnost pole typu timestamp?
    Rozdíly v řeči a ve zvyklostech neznamenají vůbec nic, budeme-li mít stejné cíle a otevřená srdce.
    Řešení 1× (K. T. Schnikow (tazatel))
    2.6.2008 09:35 Bilbo
    Rozbalit Rozbalit vše Re: MySQL a záhadně propojené sloupce
    Strucne receno, sloupec typu TIMESTAMP se updatuje sam a to na hodnotu kdy bylo naposledy s radkem hybano, proste takove automaticke datum posledni zmeny - pokud mu neni prirazena explicitne jina hodnota (coz je feature a ne bug :)

    Presne je to chovani popsano v manualu: http://dev.mysql.com/doc/refman/5.0/en/timestamp.html

    Ve starsich verzich (4.1 a starsi) se to chovani pak jetse trochu lisi od nejnovejsi.
    2.6.2008 09:42 dustin | skóre: 60 | blog: dustin
    Rozbalit Rozbalit vše Re: MySQL a záhadně propojené sloupce
    Přesně tak. Autor asi chtěl použít typ DATETIME.

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.