Příspěvky

1

Vývoj / Re:Moderný frontend - ako na to?

« kdy: 11. 07. 2025, 10:00:42 »

Zdějši komunitě se to pravděpodobně líbit nebude, ale stejného efektu jako Javascriptové frameworky můžeš docílit například pomocí Nette(+ nějaká knihovna k tomu, ale nevybavuju si, jak se jmenuje) a před nějakou dobou tohle implementovalo i Symfony - Turbo UX. V podstatě máš předpřipravenou javascriptovou knihovnu, která za tebe vyřeší AJAX komunikaci(+ nějaké routování atd) a na pozadí to funguje tak, že renderuješ vše na backendu a do front-endu se jen dosadí výsledné vyrenderované HTML, které se tahá přes AJAX. Funguje to jako SPA aplikace, máš tam své pohodlí toho, že se nemusíš učit frontendový framework a děláš pořád na backendové části. Samozřejmě nějaké specifické věci si můžeš doprogramovat. Na menší weby určitě stačí, na větších projektech s tím nemám zkušenost.

2

Hardware / Identifikace USB zařízení - FTDI

« kdy: 24. 02. 2024, 09:28:35 »

Zdravím,

převzali naprosto zpackaný systém pro fitness centrum, kde se využívá hardware od nejmenovaného ne moc dobrého a spolehlivého dodavatele pro turnikety a skříňky. S dodavatelem jsme se několikrát bavili, je to akorát banda vychcánků, co převzali nějaký historický produkt, kterému nerozumí a pak ho nabízí dál. Spoustu věcí v systému se nám podařilo napravit, nicméně jedna stále přetrvává a je dost otravná, jak pro nás tak pro zaměstnance fitness centra, potažmo jejich zákazníky.

Do serverovny vedou USB kabely ze zařízení do převodníků, které umožní přenášet data po síti, aby se dostaly na server. Na serveru běží driver FTDI, který to převádí zase na COM zařízení. Na serveru(Windows) mají COM zařízení vlastní číslo ve specifickém pořadí(COM10, 11 ... ). Na jedné lince se komunikuje s vícero zařízeními najednou, kdy se na sběrnici zasílá adresa + nějaká instrukce.

Jádro problému nastává, když ve fitku je krátkodobý výpadek proudu či jakýkoliv způsobem nastane, že se zařízení vyrestartuje a na serveru se následně přehází čísla COMů. Obslužný software pak prostě neběží, protože má nakonfigurované specifické COM porty a nekomunikuje tak se správným zařízením. Server je napojený na UPS, nicméně turnikety, převodníky nikoliv.. Aktuálně se to řeší prostě tak, že recepce všechny kabely vypojí a pak je zapojuje ve správném pořadí, což je fakt neskutečná otrava, ještě když je tam třeba z recepce někdo nový a třeba nemá přístup do serverovny.

Ideální by bylo, pokud by se mi nějak podařilo zařízení identifikovat a následně obslužný software za běhu překonfigurovat na právě platný COM port. Bohužel pokud vyhledám HardwareID ve vlastnostech COMu ve správci zařízení, tak je u každého nějaké generické ID vytvořeno FTDI driverem(FTDIBUS\COMPORT&VID_0403&PID_6001) .. Jediná hodnota kterou jsem u všech COMů našel a trochu se liší je "Physical device object name" - nevím však jestli mi to nějak pomůže ..

Rád bych se tedy zeptal zdejších lidí, pokud má někdo zkušenosti s FTDI, jestli je něco takového řešitelné a jde se nějak dostat k tomu, aby se COM port dal nějak jednoznačně identifikovat?

Čistě teoreticky mě pak napadlo ještě řešení, kdy bych se snažil komunikovat s koncovými zařízeními na každém COM portu a následně z toho vydedukoval, které je které podle toho, jestli by něco odpovídalo nebo nikoliv. Je to takové trochu přes koleno, ale asi by to jako poslední možnost šlo.

Předej děkuji za jakoukoliv odpověď.

3

Distribuce / Oprava rozbitého sudoers

« kdy: 28. 08. 2023, 17:46:52 »

Dobrý den,

dostal jsem od kolegy čistou instalaci Debian 12. Povedla se mi taková šikovná věc(jednou za čas se prostě stane), ke které se asi není třeba vůbec vyjadřovat :-D Editoval sem sudoers file s tím, že když mám autentifikaci skrze klíč místo hesla, tak nechci pořád zadávat heslo při zadání sudo příkazu. No a jelikož nevím na co si hraju, tak sem ještě předtím změnil shell root uživatele na /sbin/nologin .. Tak a i když sem použil "sudo visudo" a dal zapsat, tak sem ten soubor nějak dojebal - asi sem tam nastavil špatně hodnotu? Tak a jelikož mi nevadí, že budu za kreténa tady, ale né před svým kolegou, tak se zde ptám, zda-li to lze nějak ještě spravit. Je to server v datovém centru, nemůžu disk namountovat někam jinam, případně pustit nějakou live distribuci. Mám pouze příkazovou řádku a svůj nefunkční sudo účet :-D

Zkoušel jsem su -s /bin/bash nebo su -s /bin/bash -c "/usr/sbin/usermod -s /bin/bash root" ale to skončí tímto:

su: using restricted shell /sbin/nologin
This account is currently not available.

Někde jsem ještě našel, že existuje nějaký pkexec, ale ten balíček nemám nainstalovaný, tudíž to nepůjde.

Je tomu ještě nějak pomoci, nebo budu muset kolegovi přiznat, že jsem prostě kretén? :-D Naštěstí mám home-office, tak se mu při tom aspoň nebudu muset dívat do očí.

Děkuji :-)

4

Server / Re:Restartování serveru v noci

« kdy: 04. 10. 2021, 13:31:07 »

Server je virtuál v datovém centru - tohle jsem neuvedl. Kontaktoval jsem správce virtualizace a údajně je to problém v datovém centru, tudíž z logů nic nevyčtu. Díky všem za ochotu pomoci.

5

Server / Restartování serveru v noci

« kdy: 04. 10. 2021, 10:08:06 »

Zdravím,

potřeboval bych trochu pomoci s identifikací důvodu "náhodného" restartování Ubuntu 18.04 serveru.

Posledních pár dní dochází k restartu každý den v noci 00:00 - 03:00..

journactl --list-boots

Kód: [Vybrat]

-6 1f8c4e06cfcd4c0c982dfd6c8f5d4c12 Sun 2021-08-29 07:53:20 CESTâFri 2021-09-24 22:07:33 CEST
-5 1c6c2a36275a450dab9ce15030260be4 Fri 2021-09-24 22:08:49 CESTâSat 2021-09-25 09:46:01 CEST
-4 3743b21089af4bbe87a99dee5d8be1e6 Sat 2021-09-25 09:46:27 CESTâFri 2021-10-01 20:05:41 CEST
-3 7f103f8d0d664e299863c5648d2ec086 Fri 2021-10-01 20:07:28 CESTâSat 2021-10-02 02:13:09 CEST
-2 2af1e19285d64812a5ce5d47c99208c3 Sat 2021-10-02 02:14:42 CESTâSun 2021-10-03 00:47:30 CEST
-1 7e07f9a0aff44b129e21c1959c11b670 Sun 2021-10-03 00:48:50 CESTâMon 2021-10-04 01:03:49 CEST
 0 44dd9821fd3c4c4a94593372cf0a85be Mon 2021-10-04 01:04:48 CESTâMon 2021-10-04 10:00:44 CEST
Při procházení journactl u konkrétního záznamu nenaleznu nic. Záznamy končí neúspěšným příhlášením na roota boty:

Kód: [Vybrat]

Oct 04 01:03:47 csfitness sshd[10254]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=88.120.105.119  user=root
Oct 04 01:03:49 csfitness sshd[10254]: Failed password for root from 88.120.105.119 port 20329 ssh2
Oct 04 01:03:49 csfitness sshd[10254]: Received disconnect from 88.120.105.119 port 20329:11: Bye Bye [preauth]
Oct 04 01:03:49 csfitness sshd[10254]: Disconnected from authenticating user root 88.120.105.119 port 20329 [preauth]
Příkazy who, history, last vypadají OK.. V logu /var/log/kern.log naleznu dnes logy pouze od 06:25 - což je divné? Nemám s hlubší analýzou systému zkušenosti.. Budu rád za jakoukoliv radu, jak nalézt příčinu restartu..

Děkuji.