Tato stránka je součástí projektu:
Projekt: Hesla Jednoty bratrské
Příslušnost: skupinová

Projekt: Hesla Jednoty bratrské pro rok 2023

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:

Přípravu obálky řešíme v článku Projekt: Hesla Jednoty bratrské/obálka/2023.
Heslo roku řešíme v článku Projekt: Hesla Jednoty bratrské/heslo roku/2023
Kulatá výročí řešíme v článku Projekt: Hesla Jednoty bratrské/výročí/2023.
Písně řešíme v článku Projekt: Hesla Jednoty bratrské/písně/2023.
Názvy biblických knih: Projekt: Hesla Jednoty bratrské/knihy/2023.

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

2021-06-11 po

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

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

2021-11-12 po

Navazuji komunikaci s Inyšem ohledně Hesel 2023

2022-01-09

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

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

2022-01-14

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:

stackoverflow.com(2020-01-30): ERROR: Loading local data is disabled - this must be enabled on both the client and server sides

Je nutno:

Nastavit globální proměnnou:

 mysql> SET GLOBAL local_infile=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

2022-01-14 pátek

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

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

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

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

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

Projekt na lokálním stroji

Podadresáře:

hes23
hes23test

2022-01-17 pondělí

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

w06-dulos

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ý

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

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:

https://www.profitux.cz/aplikace/zaheslovani-adresare

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

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

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+

2022-01-22 sobota

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

2022-01-28 pátek

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

2022-02-02 středa

Došel jsem do 2023-09-02

2022-02-03 čtvrtek

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

Iny revize do 2023-02-28

2022-02-05 sobota

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

Dělal jsem na Projekt: Hesla Jednoty bratrské/výročí/2023: Porovnání verzí
Prošel jsem dny s poznámkami editorů do konce května (poslední 2023-05-29)

2022-02-07 pondělí

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ý

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

2022-02-09 středa

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

2022-02-14 pondělí

Dělal jsem na Projekt: Hesla Jednoty bratrské/výročí/2023: Porovnání verzí
Iny dodělal revizi do konce září – do 2023-09-30

2022-02-16 středa

Dělal jsem na Hesla Jednoty bratrské/výročí/2023: Porovnání verzí
Iny dodělal revizi do konce roku – do 2023-12-31
Po Jindrovi jsem do dorevidoval do 2023-04-07 – SZ Intro: Hospodin si řekl v srdci

w09-preliminary

2022-02-20 neděle

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

2022-02-21 pondělí

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ě

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

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ý

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

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

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

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

Dohledat 100-leté výročí narození pro význačné dny:
- 1923-08-10 Ve Džbánově se narodil w: Jan Blahoslav Horký
- 1923-10-19 V Praze se narodil Renatus Schiller^[1]
- 1923-12-02 V Brně se narodil w: Miloslav Hájek

2022-03-07 pondělí

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

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

2022-02-20 neděle

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í

generuji Hesla

2022-02-23 středa

hes23preklady.tex
hes23tiraz.tex

w12-rfc

2022-03-09 středa

dulos9715_iny_2022-03-09a.sql

w13-rfc2

2022-07-12 úterý

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

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ů

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

↑ biblio.hiu.cas.cz: Schiller, Renatus, 1923-1986

[1] .hiu.cas.cz: Schiller, Renatus, 1923-1986

[1]

Projekt: Hesla Jednoty bratrské pro rok 2023

w00-Losungen

2021-06-11 po

2021-10-11 po

2021-11-12 po

2022-01-09

2021-10-11 po

w01-jet-mdb-import

2022-01-14

w02-sql-load

2022-01-14 pátek

2022-01-15 sobota

2022-01-16 neděle

w03-sql-transl

w04-quote+song

w05-local

2022-01-17 pondělí

w06-dulos

2022-01-18 úterý

2022-01-19 středa

2022-01-20 čtvrtek

2022-01-21 pátek

w07-MB+

2022-01-22 sobota

w08-prubezna_editace

2022-01-28 pátek

2022-01-28 pátek

2022-01-30 neděle

2022-02-01 úterý

2022-02-02 středa

2022-02-03 čtvrtek

2022-02-04 pátek

2022-02-05 sobota

2022-02-06 neděle

2022-02-07 pondělí

2022-02-08 úterý

2022-02-09 středa

2022-02-14 pondělí

2022-02-16 středa

w09-preliminary

2022-02-20 neděle

w10-preliminary

2022-02-21 pondělí

Písně

Internal Server Error

2022-02-22 úterý

2022-02-23 středa

2022-02-24 čtvrtek

2022-03-05 sobota

2022-03-07 pondělí

2022-03-09 středa

w11-korekt01

2022-02-20 neděle

2022-02-21 pondělí

2022-02-23 středa

w12-rfc

2022-03-09 středa

w13-rfc2

2022-07-12 úterý

2022-07-13 středa

Statistika překladů

Reference