Wikiverzita

Projekt: Hesla Jednoty bratrské/2023

< Projekt: Hesla Jednoty bratrské
Jak používat klasifikační nálepkuTato stránka je součástí projektu:
Projekt: Hesla Jednoty bratrské
Příslušnost: skupinová

Projekt: Hesla Jednoty bratrské pro rok 2023 editovat

V tomto článku řešíme průběh přípravy textu (tj. vlastních hesel pro jednotlivé dny roku) pro Hesla Jednoty bratrské 2023; další záležitosti řešíme na dalších podstránkách:

Technologie asi zůstává zhruba stejná jako dříve (viz Projekt: Hesla Jednoty bratrské/2017) a jak je uvedena na hlavní stránce Projekt: Hesla Jednoty bratrské#Technologie

Písmeno w na začátku níže uvedených oddílů znamená working directory, tj. název pracovního adresáře, ve kterém se postupně řeší jednotlivé fáze vytváření českých Hesel JB:

w00-Losungen editovat

2021-06-11 po editovat

  • Beatrice Rubin, Friedrich Reinhardt Verlag, Rheinsprung 1, 4001 Basel mi posílá manuskript Losungen für 2023 2021-05-31.docx a dalších 6 souborů

2021-10-11 po editovat

  • Erdmann mi poslal databázi Losungen für 2023 2021-10-11 Large.mdb

2021-11-12 po editovat

  • Navazuji komunikaci s Inyšem ohledně Hesel 2023

2022-01-09 editovat

  • Iny píše, že od víkendu bude mít čas na práci s Hesly.
  • 2022-01-10 odpovídám, že tedy na tom máknu

2021-10-11 po editovat

  • Píšu Erdmannovi, jestli se něco od října změnilo v databázi Losungen?
  • Erdmann mi poslal:
    • databázi Losungen für 2023 2022-01-13 Large.mdb
    • předmluvu Geleitwort Losungen 2023 - für den Druck.docx

w01-jet-mdb-import editovat

2022-01-14 editovat

  • struktura databáze je stejná, jako v minulých letech, ale:
mysql -upetr -p*** -v -v --show-warnings --local-infile hes23 < load_data_infile.sql

hlásí: 

ERROR 3948 (42000) at line 3: Loading local data is disabled; this must be enabled on both the client and server sides

Googlím, co je zase za problém:

Je nutno:

  1. Nastavit globální proměnnou:
 mysql> SET GLOBAL local_infile=1;
  1. volat mysql s přepínačem -local-infile=1
 mysql -local-infile=1 -upetr -p*** -v -v --show-warnings --local-infile hes23 < load_data_infile.sql
  • Kvůli citaci z Luthera na řádku 362
Warning (Code 1265): Data truncated for column 'Dt_Text' at row 362

Nutno rozšířit pole: 

CREATE TABLE `drittetext` (… `text` varchar(700) CHARACTER SET utf8 COLLATE utf8_czech_ci NOT NULL, …);
...
CREATE TABLE `import` (… `Dt_Text` varchar(700) CHARACTER SET utf8 COLLATE utf8_czech_ci DEFAULT NULL, …);

w02-sql-load editovat

2022-01-14 pátek editovat

  • chybí mi databáze bible
  • vytvořím a importuji z /DATA/www/dulos.wrk/cz/bible-sql/SQL/bible-adminer.sql
Příliš velká POST data. Zmenšete data nebo zvyšte hodnotu konfigurační direktivy 'post_max_size'.
  • To je problém v php.ini

2022-01-15 sobota editovat

Dohledáme si podobný problém v PhpMyAdmin/Tutoriál#Problém velikosti importovaného souboru a dle toho si to nakonfigurujeme: 

sudo emacs /etc/php/7.4/apache2/php.ini
apache2ctl restart

httpd not running, trying to start
(13)Permission denied: AH00072: make_sock: could not bind to address [::]:80
(13)Permission denied: AH00072: make_sock: could not bind to address 0.0.0.0:80
no listening sockets available, shutting down
AH00015: Unable to open logs
Action 'restart' failed.
The Apache error log may have more information.

Tak si to najdeme v Apache2#Řízení 

systemctl restart apache2

A teď znovu importujeme do databáze bible z /DATA/www/dulos.wrk/cz/bible-sql/SQL/bible-adminer.sql 

20 příkazů proběhlo v pořádku

A teď znovu: 

hes-sql-load.pl
verbose = : 2=neděle, 3=všechny dny, 4=názvy nedělí, 5=názvy svátků, 6=angaben, 7=comments, 8=DT, 9=, 10=počet Angaben, 11=vypíše Angaben, 12=původní Angaben, 13=READINGS

hes-sql-load.pl 1

        CHYBA (2023-01-01): Liší se pořadí kalendářní neděle (sun_n=1) a neděle v databázi `day` (sun_nr=0)!
        CHYBA (2023-01-06): Liší se pořadí kalendářní neděle (sun_n=1) a neděle v databázi `day` (sun_nr=0)!
        CHYBA (2023-01-08): Liší se pořadí kalendářní neděle (sun_n=2) a neděle v databázi `day` (sun_nr=1)!
        CHYBA (2023-01-15): Liší se pořadí kalendářní neděle (sun_n=3) a neděle v databázi `day` (sun_nr=2)!
…

2022-01-16 neděle editovat

Koukneme tedy do tabulky `day`. Je to tím, že 2023-01-01 připadá svátek (NEUJAHR) zrovna na neděli, ale neděle má mít přednost: 

sel date         dow    seq   which     nr  lang   text
0   2023-01-01   So     1     holiday   1   de     NEUJAHR

Musíme tedy u NEUJAHR změnit holiday na sundayv tabulce `day_cs`. A už to tedy klape.

Další problém: 

hes-sql-load.pl 2

verbose = 2
365 records:

2023-01-01 So: (1)Ft1='sunday' <1>Ft1='holiday'
2023-01-08 So: (2)Ft1='sunday'
2023-01-15 So: (3)Ft1='sunday'
2023-01-22 So: (4)Ft1='sunday'
2023-01-29 So: (5)Ft1='sunday'
2023-02-05 So: (6)Ft1='sunday'
2023-02-12 So: (7)Ft1='sunday'
2023-02-19 So: (8)Ft1='sunday'
2023-02-26 So: (9)Ft1='sunday'
2023-03-05 So: (10)Ft1='sunday'
2023-03-12 So: (11)Ft1='sunday'
2023-03-19 So: (12)Ft1='sunday'
2023-03-26 So: (13)Ft1='sunday'
Lied: '76 | 97' neobsahuje ': '!! at ./hes-sql-load.pl line 215.
2023-04-02 So: (14)Ft1='sunday'

Podíváme se do tabulky `import` do sloupce `Ft1_Lied`, datum 2023-03-26 neděle. Ale tam to vypadá, že je to v pořádku: 

Wochenlied: 76 oder 97

Možná je nějaká zpozdilá hláška, protože problém vidím u následující neděle 2023-04-02, kde je: 

Wochenlied:14 oder 91

Zkrátka ochranovským v jejich tabulce chybí mezera za dvojtečkou, takže to napravíme: Wochenlied: 14 oder 91

Výborně, teď to doběhlo až do prosince: 

2023-12-03 So: (49)Ft1='sunday'
2023-12-10 So: (50)Ft1='sunday'
2023-12-17 So: (51)Ft1='sunday'
2023-12-24 So:
        CHYBA (2023-12-24): Liší se pořadí kalendářní neděle (sun_n=52) a neděle v databázi `day` (sun_nr=51)!
         <21>Ft1='holiday'
        CHYBA (2023-12-25): Liší se pořadí kalendářní neděle (sun_n=52) a neděle v databázi `day` (sun_nr=51)!
         <22>Ft1='holiday'
        CHYBA (2023-12-26): Liší se pořadí kalendářní neděle (sun_n=52) a neděle v databázi `day` (sun_nr=51)!
         <23>Ft1='holiday'(2. svátek vánoční -> píseň jako WL kvůli duplicitě v databázi)
        CHYBA (2023-12-26): Liší se pořadí kalendářní neděle (sun_n=52) a neděle v databázi `day` (sun_nr=51)!
DBD::mysql::st execute failed: Data too long for column 'intro' at row 1 at ./hes-sql-load.pl line 107.
DBD::mysql::st execute failed: Data too long for column 'intro' at row 1 at ./hes-sql-load.pl line 107.
         <24>Ft2='holiday'
---KONEC---

Takže to bude zřejmě obdobný problém, že Štědrý den 2023-12-24 připadá zrovna na neděli, takže neděle musí mít přednost. V tabulce `day` máme: 

sel date         dow  seq  which     nr   lang  text
0   2023-12-24   So   72   holiday   21   de    HEILIGER ABEND

Takže to opět musíme napravit v tabulce `day_cs`: 

sq	 text_de	      sel	date	which     text
740  HEILIGER ABEND   1     NULL    holiday   Štědrý den

změnit na: 

sq	 text_de	      sel	date	which    text
740  HEILIGER ABEND   1     NULL    sunday   Štědrý den

Změnu zazálohujeme do hes23w02e-2023-12-24_HEILIGER_ABEND.sql

Takže ještě nám na konci roku zbývá vyřešit: 

hes-sql-load.pl 3

2023-12-21 Do: OT+NT SR+CR
2023-12-22 Fr: OT+NT SR+CR
2023-12-23 Sa: OT+NT SR+CR
2023-12-24 So: (52)Ft1='sunday'+text OT+NT
2023-12-25 Mo: <21>Ft1='holiday'+text OT+NT
2023-12-26 Di: <22>Ft1='holiday'+text(2. svátek vánoční -> píseň jako WL kvůli duplicitě v databázi) <23>Ft2='holiday'+text OT+NT
2023-12-27 Mi: OT+NT SR+CR
2023-12-28 Do: OT+NT SR+CR
2023-12-29 Fr: OT+NT SR+CR
DBD::mysql::st execute failed: Data too long for column 'intro' at row 1 at ./hes-sql-load.pl line 107.
DBD::mysql::st execute failed: Data too long for column 'intro' at row 1 at ./hes-sql-load.pl line 107.
2023-12-30 Sa: OT+NT
---KONEC---

Na 2. svátek vánoční+Štěpána 2023-12-26 máme v ochranovské tabulce: 

 Ft1_Lied: Lied: 32 oder 39
 Ft2_Lied: Lied: 137 oder 154

A s tím se v naší databázi nepočítá, že v jednom dni budeme mít dvakrát Lied, proto skript tu druhou automaticky označil jako WL = Wochenlied. Je to taková obezlička, ale zavádět kvůli jednomu dni v roce zase další kategorii písní, to se mi nechtělo.

Zbývá ještě podívat se na ten Los_Vortext ke dni 2023-12-30 

Josef sprach zur Frau des Potifar, die ihn verführen wollte:

Zkrátka delší Intro, než jaké jsme kdy měli – 60 znaků. Máme tam sice rezervovaných 60 znaků, ale ta přehláska zabírá 2 bytes, tak to bude asi tím. Prodloužíme tedy sloupec na 65 znaků. Ale nepomohlo to! Jak to??

No jo, blbnu, Los_Vortext do tabulky `intro` se přeci vešel, ale do tabulky `losung` se to teď nevejde, musím to prodloužit tam, mám tam jenom 50 znaků, musím změnit také na 65: 

CREATE TABLE `losung` (
…
  `intro` varchar(65) CHARACTER SET utf8 COLLATE utf8_czech_ci DEFAULT NULL,
…

Tak to prošlo, ale:

Ještě (snad) poslední problémek se samotným koncem roku, kde Silvestr připadá opět na neděli: 

2023-12-27 Mi: OT+NT SR+CR
2023-12-28 Do: OT+NT SR+CR
2023-12-29 Fr: OT+NT SR+CR
2023-12-30 Sa: OT+NT SR+CR
2023-12-31 So:
        CHYBA (2023-12-31): Liší se pořadí kalendářní neděle (sun_n=53) a neděle v databázi `day` (sun_nr=52)!
         <24>Ft1='holiday'+text OT+NT
---KONEC---

Takže se podíváme, jak se nám to vygenerovalo německy v tabulce `day`: 

sel date         dow    seq   which     nr  lang   text
0   2023-12-31   So     76    holiday   24  de     ALTJAHRSABEND

a pak podle toho opravit holiday ALTJAHRSABEND na sunday v tabulce `day_cs`: 

sq	 text_de	      sel	date	which     text
780  ALTJAHRSABEND    1     NULL    holiday   Závěr roku

Takže nakonec ještě projedeme s maximální verbositou: 

hes-sql-load.pl 13

Vypadá to dobře, takže zazálohujeme do: 

hes23w02i-ALTJAHRSABEND.sql

a jedeme na překlad do češtiny.

w03-sql-transl editovat

Překlad do češtiny: 

./hes-sql-transl.pl > errors-e 2>&1

        !! reading 2023-11-10, seq=0, which=SR: Nejeden (0E0) překlad 'Matthäus12,32-37'->'Matthäus12,32-37'
DBI::db=HASH(0x562dda91b200)->disconnect invalidates 4 active statement handles (either destroy statement handles or call finish on them before disconnecting) at ./hes-sql-transl.pl line 18
2.
       day:  76 rows
   reading: 929 rows
    losung: 808 rows
…

No jo, ochranovští zapomněli mezeru za názvem knihy, takže opravíme ve dni 2023-11-10 ve sloupci Bibellese_1 v tabulce `import` a pak to celé zase znovu přegenerujeme.

Pak už to všechno projelo dobře.

Nicméně ty tabulky v přehledu admineru mi přijdou nějcké chudé, oproti minulému roku. Jako by to někde zkolabovalo :-( Ale velikost exportu hes23w03a.sql 1047837 bytes je zhruba stejná, jako bylo vloni u hes22w03a 1044899 bytes, tak se mi asi v tom admineru jen něco blbě zobrazuje :-(

Jestli jenom něco zůstalo viset v cache Firefoxu?

Mažu cache, nepomáhá.

Adminer verze 4.7.6, přeinstaluji jej – nepomáhá.

Zkrátka sotva kliknu na http://localhost/adminer/?username=petr&db=hes23 tak tam vidím nějakou starou tabulku, ve které ty velikosti neodpovídají.

Sotva přejmenuji databázi hes23 na cokoli jiného, zobrazuje se mi to dobře. Ale sotva ji přejmenuji zase zpátky, ukazuje to blbě.

Zkusím založit novou databázi a naimportovat exportovaná data, a je to pořád to samé.

Zkouším to v Google Chrome, a zase to nepomáhá.

Nechápu, co se děje. Dobře, nechám to tak, je to hloupé, ale na samotný běh programů by to mít vliv nemělo.

w04-quote+song editovat

  • quotes23void.pl – přidám do databáze prázdné záznamy pro dny, kdy budou mět být citáty
  • song-de+data+EZ+BZ.pl – zanese do tabulky song názvy německých písní s odkazy do http://www.liederdatenbank.de/
|0|2022-11-20|67| WL|de|  |147 / 535 | 153| 0| 0||
!!!147 / 535 | 153!!! at ./song-de+data+EZ+BZ.pl line 42,  line 591

Už jsme měli ten samý problém vloni i předloni: Tak prostě vyhodím to / 535 z té tabulky song 2022-11-20 A prošlo.

Ještě zazálohuji vše dosavadní: 

tar cjf hes23w04b.tar.bz2 2023

w05-local editovat

Projekt na lokálním stroji

Podadresáře:

  • hes23
  • hes23test

2022-01-17 pondělí editovat

  • přesun definicí z functions.php do
  • doplnění formuláře
  • příprava na upload
  • doladění

w06-dulos editovat

  • import letošních dat do databází
  • upload skriptů

Nastavení hesla: 

python3

import crypt
crypt.crypt("nějakÉhesloHeslo", crypt.METHOD_MD5)

 '$1$WWo.ma2b$eViMDy1cA8EtYXXllexk60'

S podivem zjišťuji, že nastavení přístupového hesla pro nového uživatele nějak nefunguje. Nejen, že nefunguje, ale všechno se to chová nějak podivně a záhadně. Ale musím už jet do práce, takže slíbené předání skriptu novému uživateli pro zahájení editace Hesel jsem nestihl.

2022-01-18 úterý editovat

Od rána máme předtermín, skoro celý den jsem v práci, takže záhadu řeším zase až večer – stále neúspěšně.

2022-01-19 středa editovat

  • Dopoledne posílám editorovi alespoň Geleitwort na překlad. A odpoledne omluvu, že to ještě nefunguje, a vymlouvám se na nového providera.
  • V noci ještě pokračuji ve zkoumání a zjišťuji, že má výmluva na jiného providera skutečně měla něco do sebe. Trocha historie:

Posledních asi 20 let měl své WWW stránky u jedné malé firmičky https://www.profitux.cz/ , což byla zřejmě firma jednoho muže Pavla Šišky, podnikal jako živnostník původně na Žižkově, Českobratrská 11, což mi bylo sympatické, a vše běželo pod Linuxem, což mi bylo ještě sympatičtější. Nejspíš celé dny i noci seděl u monitoru, protože v jakoukoli hodinu jsem mu něco napsal, tak během několika minut odpověděl a věděl všechno o všem, neboť si to všechno nejspíš sám postavil. Ceny příjemné, funkce dokonalá.

A pak se stalo, že mi namísto něj začal odpovídat nějaký Team ProFiTux.cz, pak nějaký připitomělý robot Čestmír a po něm nějací Sales and Support Specialisté a jednatelé atd. z Profitux s.r.o. z Jablonce, kteří už nevěděli nic, no a vloni na podzim jsem se dověděl, že všechny servery Profitux budou postupně migrovat pod https://www.webglobe.cz/ , tak abych se moc nedivil, když se občas vyskytne nějaký problémek.

  • 2021-10-18 mi přišel z Webglobe <helpdesk@webglobe.cz> e-mail, zhruba řečeno:

Včera proběhla migrace dat Vašich webových stránek ze serveru rory.profitux.cz do nového administračního prostředí Webglobe Admin. Rádi bychom Vás poprosili o překontrolování funkčnosti Vašich webů. Migrace se týkala následujících domén: dulos.cz Chceme Vás ještě upozornit, že původní FTP root byl přesunut do adresáře /public_html/. Prosím změňte si ve Vašem připojení FTP cestu k adresáři, např. /www/ na /public_html/www/

Pokud jste po migraci zaznamenali jakoukoliv nesrovnalost na Vašich webech nebo potřebujete pomoci s Vašimi službami, obraťte se na naši zákaznickou podporu na telefonním čísle +420 603 111 111 nebo prostřednictvím e-mailu na helpdesk@webglobe.cz Průběh migrace můžete také sledovat na webu https://migrace.profitux.cz/

Napadlo mě novu se podívat na návod na zaheslování adresáře u původního providera, jak jej dávno napsal Pavel Šiška/Profitux:

A tak jsem znovu pomocí phpinfo() ověřil proměnnou SCRIPT_FILENAME. A ejhle! Zatímco původně cesta začínala: 

/home/ftpsite/dulos.cz/

nyní to bylo bez jakéhokoliv upozornění změněno na: 

/home/html/dulos.cz/public_html/

Což mi předtím uniklo pozornosti, protože přístup k zaheslovaným adresářům pro staré uživatele fungoval stále normálně! Asi to soudruzi prostě museli nějak zabastlit nějakými obezličkami, kteréžto obezličky jim přestaly fungovat v okamžiku, kdy jsem chtěl přidat nového uživatele, a vznikl tím totální chaos. Tak jsem si to vysvětlil a byla půlnoc.

2022-01-20 čtvrtek editovat

Ráno moudřejší večera. Přepsal jsem tedy v klidu všechny potřebné konfiguráky a ejhle, vše začalo fungovat jako na drátku.

Těsně před polednem tedy konečně píšu e-mail novému editorovi, že může začít s editací Hesel JB 2023, a potřebné instrukce k tomu.

2022-01-21 pátek editovat

Jedna maličkost mě zaujala: Pokud dám do URL adresář, který nemá povolený přístup, tak:

  • v případě, že adresář ukončím lomítkem, zobrazí se mi:
403 Forbidden
You don't have permission to access this resource.
  • v případě, že adresář neukončím lomítkem, zobrazí se mi:
                               403 Forbidden
––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––––
                                    nginx

Nevím, jestli to něco znamená. Ale každopádně z toho vidím, že to neběží na Apache, ale na w: Nginx.

w07-MB+ editovat

2022-01-22 sobota editovat

Je to divné, phpMyBackupPro v.2.4 nehlásí nginx, ale: 

System information
Server
Apache 	 	Time: 2022/01/22 11:40:46
PHP
PHP Version: 5.6.40-57+0~20211119.60+debian10~1.gbp8a9bd1 	 	  	 	PHP Memory Limit: 256M
gzip compression possible: yes 	 	Emails sendable: yes 	 	FTP transfer possible: yes
MySQL
MySQL Server: 5.5.62 	 	MySQL Client: mysqlnd 5.0.11-dev - 20120503 - $Id: 76b08b24596e12d4553bd41fc93cccd5bac2fe7a $

Možná to bude tím, že Nginx to přehodí na Apache.

Zkontrolované editace:

  • 13:00 – do neděle 2023-01-08
  • 19:30 – do neděle 2023-01-15

w08-prubezna_editace editovat

2022-01-28 pátek editovat

  • Iny došel do 2023-07-31
  • Projel jsem to po něm.

2022-01-28 pátek editovat

2022-01-30 neděle editovat

2022-02-01 úterý editovat

2022-02-02 středa editovat

  • Došel jsem do 2023-09-02

2022-02-03 čtvrtek editovat

  • Iny dojel do konce roku 2023-12-31
  • A pak znovu revizi do 2023-01-31
  • Já jsem po něm došel do jen 2023-10-04

2022-02-04 pátek editovat

  • Iny revize do 2023-02-28

2022-02-05 sobota editovat

  • Ráno jsem došel do 2023-12-31
  • Iny revize do 2023-03-31
  • Vytisknu si všechny poznámky editorů za celý rok:
SELECT `date`,`text` FROM `notice` ORDER BY `date`;
  • A pak projíždím také znovu případy, kde byly nějaké ty poznámky.
    • Dojedu do 2023-04-12

Statistika překladů

Zdroj počet % SQL
Celkem 815 100 SELECT * FROM `losung` WHERE `sel` = '1' ORDER BY `date` LIMIT 1000;
ČEP 740 90,8 SELECT * FROM `losung` WHERE `sel` = '1' AND `transl` LIKE 'cep' ORDER BY `date` LIMIT 1000;
Kral 38 4,7 SELECT * FROM `losung` WHERE `sel` = '1' AND `transl` LIKE 'kra' ORDER BY `date` LIMIT 1000;
Jiný 37 4,5 SELECT * FROM `losung` WHERE `sel` = '1' AND `transl` LIKE 'oth' ORDER BY `date` LIMIT 1000; 
SELECT * FROM losung WHERE lang LIKE 'cs' AND transl LIKE 'oth' AND SEL=1 ORDER BY REVERSE(source);
Rozpis jiných překladů:
Zdroj počet %
Jiný 37 100 Celkem jiných
B21 4 11 Bible 21 – Flek
F 16 43 Fischl
H 2 5 Hejčl
J 1 3 Jeruzalémská – manž. Halasovi
L 3 8 Losungen – přímý překlad
Col 2 5 Col
R 2 5 Renč
Ž 7 19 Žilka
  • Posílám Inymu

2022-02-06 neděle editovat

2022-02-07 pondělí editovat

  • Dělal jsem na Projekt: Hesla Jednoty bratrské/výročí/2023: Porovnání verzí
  • Iny dodělal revizi dubna – do 2023-04-30
  • Já jsem ještě prošel naše předchozí poznámky dokonce července 2023-07-30
  • Ještě jsme spolu řešili Žalm 91,9, rozdělený do dvou Hesel: 91,9a 2023-04-11 a 91,9b 2023-01-24. Nakonec jsme se rozhodli pro odklon od Luthera a dali jsme ČEP.

2022-02-08 úterý editovat

  • Iny dodělal revizi května – do 2023-05-31

2022-02-09 středa editovat

  • Iny dodělal revizi června–července – do 2023-07-31

2022-02-14 pondělí editovat

2022-02-16 středa editovat

w09-preliminary editovat

2022-02-20 neděle editovat

  • Po Jindrovi jsem do dorevidoval do 2023-04-07
  • Vsunu výročí
  • Předběžná sazba – měsíce + perikopy
  • Posílám Inymu

w10-preliminary editovat

2022-02-21 pondělí editovat

  • Pročistím jednotlivé měsíce
  • Trochu poupravím skripty na perikopy
  • Dále:
    • hes23titul.tex
    • hes23copy.tex
    • hes23uvod.tex
    • hes23vyroci.tex – jen obrys
    • hes23preklady.tex
SELECT * FROM losung WHERE lang LIKE 'cs' AND transl LIKE 'oth' AND SEL=1 ORDER BY REVERSE(source);
Rozpis jiných překladů:
Zdroj počet %
Jiný 34 100 Celkem jiných
B21 3 8 Bible 21 – Flek (včetně hesla roku)
Col 1 3 Col
F 17 50 Fischl
H 2 6 Hejčl
KLP 2 6 Katolický litugický
L 1 3 Losungen – přímý překlad
R 2 6 Renč
Ž 7 20 Žilka

Písně editovat 

SELECT nr, book, strophe, date FROM song WHERE lang LIKE 'cs' AND SEL=1 ORDER BY book, nr, strophe, date;

Zjišťuji, že se nám tu dubluje: 

nr  book  strophe  date
309  EZ     1   2023-02-12
309  EZ     1   2023-10-01

SELECT date, seq, source FROM reading WHERE lang LIKE 'cs' AND which LIKE 'CR' AND SEL=1 ORDER BY DATE;

Internal Server Error editovat

Píše Honza, že se nemůže zalogovat: 

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.

Bohužel, error logy se mi po migraci od Profitux k Webglobe (já jsem dobrovolně nemigroval, ale Webglobe to požral a já si u něj už stěžuji několik měsíců) stále nezobrazují.

Píšu tedy další stížnost: 

Vážený pane,
už to bude měsíc, co jste mi slíbil, že to předáte k řešení k migračnímu týmu a pořád nic!
* Acces logy mi chodí zabalené jednou denně a ještě k tomu tak vybrakované, že v nich žádná naše aktivita vidět není
* Error logy nechodí žádné.

Zrovna dneska se mi tam zákazník nemůže dostat, že po zalogování obdrží hlášku:

Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.

Tak co mu mám prosím napsat?
Že vaše společnost Webglobe ještě za půl roku nebyla schopna dokončit migraci mého webu a i když váš server do celého světa rozhlašuje, že informace o chybě jsou v error logu, tak že mi žádné error logy neposkytuje??
Že se nestydíte!

Petr Heřman

2022-02-22 úterý editovat

Přišla odpověď: 

Dobry den,

žádné logy náš systém neposílá. Všechny logy jsou na FTP hostingu.

kde přesně a při jakém úkonu máte daný Internal Server Error?

Pre hodnotenie odpovede a zobrazenie historie spravy kliknite na:
https://www.onlinepodpora.sk/ticket_8ZbCot1QSHtLd4Xw

S pozdravom / Best regards
Robert Masir
webglobe.com | domena.cz | domena.sk | wy.sk | stable.cz | hosting90.cz | endora.cz

Vinohradská 190/2405, 130 61 Praha 3, Česká republika

Stará Prievozská 2, 821 09 Bratislava, Slovenská republika

2022-02-23 středa editovat

Prozkoumávám celý svůj web, hledám, kde by ty logy mohly být, testuji, a pořád kde nic tu nic. Píšu tedy již rozhořčenou odpověď na Robert Masir <helpdesk@webglobe.cz>: 

Dne 22. 02. 22 v 11:14 Robert Masir napsal(a):
> Dobry den,
>
> žádné logy náš systém neposílá. Všechny logy jsou na FTP hostingu.

Právě že tam žádné error logy nenacházím! Vždyť Vám to opakuji už poněkolikáté!

Na starém profitux serveru jsme měl logy v adresáři /_logs
V tomto adresáři jsem měl všechny aktuální logy za posledních 7 dní, a to pro každou subdoménu zvlášť, např:

hesla.dulos.cz.2021.08.13.access.log
hesla.dulos.cz.2021.08.14.access.log
hesla.dulos.cz.2021.08.14.error.log
hesla.dulos.cz.2021.08.15.access.log
hesla.dulos.cz.2021.08.15.error.log
hesla.dulos.cz.2021.08.16.access.log
hesla.dulos.cz.2021.08.17.access.log
hesla.dulos.cz.2021.08.17.error.log
hesla.dulos.cz.2021.08.18.access.log
hesla.dulos.cz.2021.08.18.error.log
hesla.dulos.cz.2021.08.19.access.log
hesla.dulos.cz.2021.08.19.error.log
hesla.dulos.cz.2021.08.20.access.log

Tento adresář /_logs tam už nemám. Namísto něj mám vše zagzipované v adresáři /logs
Na tuto změnu jste mě také při migraci neupozornili!
Musel jsem si na to přijít sám, když mě zase něco přestalo fungovat, co předtím fungovalo!

A v tomto adresáři nyní mám už jen:
dulos.cz-access-2022-02-16.log.gz
dulos.cz-access-2022-02-17.log.gz
dulos.cz-access-2022-02-18.log.gz
dulos.cz-access-2022-02-19.log.gz
dulos.cz-access-2022-02-20.log.gz
dulos.cz-access-2022-02-21.log.gz
dulos.cz-access-2022-02-22.log.gz

Když to rozzipuji, mám tam jen:
dulos.cz-access-2022-02-16.log
dulos.cz-access-2022-02-17.log
dulos.cz-access-2022-02-18.log
dulos.cz-access-2022-02-19.log
dulos.cz-access-2022-02-20.log
dulos.cz-access-2022-02-21.log
dulos.cz-access-2022-02-22.log

Tj. jen samé zagzipované access logy a žádný error log!

Navíc tyto access logy obsahují jen přístupy metodou GET a žádný přístup metodou POST!

Např. dnes:

77.88.9.3 - - [22/Feb/2022:04:33:41 +0100] "GET /robots.txt HTTP/1.1" 404 196 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"                                                               
77.88.9.3 - - [22/Feb/2022:04:33:45 +0100] "GET /mac/cz/jb/cas/jb9704.htm HTTP/1.1" 404 184 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"                                                 
207.46.13.153 - - [22/Feb/2022:05:20:45 +0100] "GET /ascii/cz/jb/cas/jb9610.htm HTTP/1.1" 404 184 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)"                                    
77.88.9.11 - - [22/Feb/2022:06:08:06 +0100] "GET /cz/jb/cas/jb9607.htm HTTP/1.1" 200 32649 "-" "Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)"                                                  

Na bývalém profitux serveru bylo běžně např.:

185.14.232.13 - mirek [25/Feb/2021:10:03:40 +0100] "POST /***/***/index.php HTTP/1.1" 200 2948 "http://hesla.dulos.cz/2022/mirek/" "Mozilla/5.0 (Windows NT 6.1; rv:86.0) Gecko/20100101 Firefox/86.0"          
185.14.232.13 - mirek [25/Feb/2021:10:03:51 +0100] "POST /***/***/index.php HTTP/1.1" 200 2585 "http://hesla.dulos.cz/2022/mirek/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:86.0) Gecko/20100101 Firefox/86.0"
185.14.232.13 - mirek [25/Feb/2021:10:03:52 +0100] "POST /***/***/index.php HTTP/1.1" 200 2508 "http://hesla.dulos.cz/2022/mirek/index.php" "Mozilla/5.0 (Windows NT 6.1; rv:86.0) Gecko/20100101 Firefox/86.0"

Tj. viděl jsem tam, kdo se pod jakým username logoval.
Tyhle položky prostě v současných access lozích chybí!

Na to jsem Vás upozorňoval už dávno a slíbil jste, že to předáte k řešení Vašemu týmu. Předal jste? Co Váš tým za tu dobu vyřešil??
> kde přesně a při jakém úkonu máte daný Internal Server Error?

Např. při pokusu o zalogování:
http://hesla.dulos.cz/2023/test
Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator at [no address given] to inform them of the time this error occurred, and the actions you performed just before this error.

More information about this error may be available in the server error log.

---

A žádný error log se mi v adresáři /_logs neobjeví!!!!!

Píšu to snad málo jasně??? Řešíme to spolu už déle jak měsíc a pořád žádná náprava z Vaší strany!

Před měsícem jste mi napsal:
Dne 21. 01. 22 v 9:44 Robert Masir napsal(a):
> Dobry den,
>
> 1/ neevidujeme problém adresář si klasicky můžete vybrat.
>
> Body 2-5 jsou běžná funkce našeho systému, pokud požadujete něco specifického asi je na místě zvažovat vlastní virtuální server.
>
> Access logy se generují jednou denně a php error log se vytvoří pouze pokud vznikne nějaky problem na webu v rámci php.

Takže jak tomu mám rozumět??
Jak mám zjistit, kde nastal problém??
> Pre hodnotenie odpovede a zobrazenie historie spravy kliknite na:
> https://www.onlinepodpora.sk/ticket_8ZbCot1QSHtLd4Xw
>
> S pozdravom / Best regards
> Robert Masir

Petr Heřman
  • Večer Putin okupuje Donbas

2022-02-24 čtvrtek editovat

  • Odjíždíme do lesa, na Hesla se už tím pádem 10 dní nedostanu.
  • Putin napadá celou Ukrajinu. Dát do Výročí na příští rok.

2022-03-05 sobota editovat

  • 22:46 Posílám oficiální požadavek na Podporu Webglobe:
Object of request: dulos.cz (409672)
Priority: Middle
Department request: Helpdesk
Subject of the request : dulos.cz-access.log
Requirement description:
Dobrý večer, už to s panem Robertem Masirem řešíme několik měsíců a pořád žádný výsledek:
1) V dulos.cz-access.log vůbec nejsou záznamy o přístupech metodami POST, ale pouze GET
2) Potřebuji mít aktuální access.log a nikoli čekat celý den a noc, než se mi někde objeví zazipovaný log za 24 hodin (a ani to není od 00:00 do 23:59). U providera PROFITUX bylo naprosto normální, že se mi do jednoho souboru neustále načítaly další řádky OKAMŽITĚ po zpracování požadavku serverem

Control ticket: 369809-840125

2022-03-07 pondělí editovat

Odpověď z Webglobe: 

Dobry den,

všechny error logy neposkytujeme v zákaznickém error logu, to jsem zmínil již dříve. Daný error jsem vytáhl z serverového logu.

Pokud Vám chybí v access logu POST requesty, požádám Vás o konkrétně, které, protože POST requesty by se měly normálně logovat a nikde jinde nezaznamenáváme problém s tím, že by se nezpracovávaly.

Logy ne nezpracovávají průběžně, ale jednou za 24hodin. To nezmění, tak funguje náš logovací systém.

Veškeré info o migracích chodilo emailem, pokud jste informace nedostal, je nutné říct jaké konkrétní Vám před/po/během migrace chyběly.

S pozdravom / Best regards
Robert Masir
webglobe.com

2022-03-09 středa editovat

Odpovídám: 

Dne 07. 03. 22 v 0:09 Robert Masir napsal(a):
> Dobry den,
>
> všechny error logy neposkytujeme v zákaznickém error logu, to jsem zmínil již dříve. Daný error jsem vytáhl z serverového logu.

Dobrý den, tak to také nechápu. Proč takový error, jakým je nepřítomnost souboru s hesly, v zákaznickém error logu neposkytujete? A kde tedy máte uvedeno, jaké logy zákazníkům poskytujete anebo ne?
> Pokud Vám chybí v access logu POST requesty, požádám Vás o konkrétně, které, protože POST requesty by se měly normálně logovat a nikde jinde nezaznamenáváme problém s tím, že by se nezpracovávaly.

Je jich mnoho: Tak např. v tu chvíli, kdy jsem posílal svůj dotaz, jsem zrovna několikrát přistupoval ke skriptu v zaheslovaném adresáři:
**************

A v dulos.cz-access-2022-03-05.log o tom není ani zmínka!

Tento skript pro vyplňování formuláře pracuje výhradně metodou POST.

> Logy ne nezpracovávají průběžně, ale jednou za 24hodin. To nezmění, tak funguje náš logovací systém.

A jak to, že na profitux.cz, ze kterého jste mě migrovali, to mohlo fungovat průběžně? V čem je problém??

> Veškeré info o migracích chodilo emailem, pokud jste informace nedostal, je nutné říct jaké konkrétní Vám před/po/během migrace chyběly.

Už jsem Vám to psal několikrát!
Tak například, že se mi od 19. října minulého roku přestaly ukládat statistiky do adresáře /public_html/hesla/stats

> S pozdravom / Best regards
> Robert Masir
> webglobe.com | domena.cz | domena.sk | wy.sk | stable.cz | hosting90.cz | endora.cz
>
> Vinohradská 190/2405, 130 61 Praha 3, Česká republika
>
> Stará Prievozská 2, 821 09 Bratislava, Slovenská republika

Petr Heřman

w11-korekt01 editovat

2022-02-20 neděle editovat

Koriguji po Inyšovi:

  • dulos9715_iny_2022-02-20a.sql
  • dulos9715_iny_2022-02-20b.sql
  • dulos9715_iny_2022-02-20c.sql
  • dulos9715_iny_2022-02-20d.sql

2022-02-21 pondělí editovat

  • generuji Hesla

2022-02-23 středa editovat

  • hes23preklady.tex
  • hes23tiraz.tex

w12-rfc editovat

2022-03-09 středa editovat

  • dulos9715_iny_2022-03-09a.sql

w13-rfc2 editovat

2022-07-12 úterý editovat

  • Hlavně korektury z I. čtvrtletí – abejas
  • dulos9715_iny_2022-07-11a.sql = stejný jako dulos9715_iny_2022-03-09a.sql – nezměnilo se
  • dulos9766_rfc_2022-07-11a.sql – po korekturách abejase

2022-07-13 středa editovat

  • Dokončeny korektury z I. čtvrtletí – abejas
  • dulos9766_rfc_2022-07-13a.sql – zkorigoval jsem mu to
  • dulos9766_rfc_2022-07-13b.sql – generuji Hesla, s chybami
  • dulos9766_rfc_2022-07-13c.sql – generuji Hesla, už bez chyb
  • editace

Statistika překladů editovat

Zdroj počet % SQL
Celkem 803 100 
SELECT * FROM `losung` WHERE `sel` = '1' ORDER BY `date` LIMIT 1000;
ČEP 722 89,9 
SELECT * FROM `losung` WHERE `sel` = '1' AND `transl` LIKE 'cep' ORDER BY `date` LIMIT 1000;
Kral 38 4,7 
SELECT * FROM `losung` WHERE `sel` = '1' AND `transl` LIKE 'kra' ORDER BY `date` LIMIT 1000;
Jiný 43 5,4 
SELECT * FROM `losung` WHERE `sel` = '1' AND `transl` LIKE 'oth' ORDER BY `date` LIMIT 1000;

SELECT * FROM losung WHERE lang LIKE 'cs' AND transl LIKE 'oth' AND SEL=1 ORDER BY REVERSE(source);
Rozpis jiných překladů:
Zdroj počet %
Jiný 43 100 Celkem jiných
B21 6 14 Bible 21 – Flek (včetně hesla roku)
Col 4 9 Col
F 18 42 Fischl
H 3 7 Hejčl
KLP 2 5 Katolický litugický
L 1 2 Losungen – přímý překlad
R 2 5 Renč
Ž 7 16 Žilka

Reference editovat

  1. ↑ biblio.hiu.cas.cz: Schiller, Renatus, 1923-1986
Citováno z „https://cs.wikiversity.org/w/index.php?title=Projekt:_Hesla_Jednoty_bratrské/2023&oldid=131544“