1. Fórum Root.cz
  2. Profil Warezjoe
  3. Zobrazit příspěvky
  4. Příspěvky

Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Warezjoe

Stran: [1]
1
Odkladiště / Re:Dlouhodobá regitrace domény
« kdy: 10. 06. 2023, 10:06:01 »
Díky moc za všechny postřehy.

O Forpsy jsem věděl, ale zkoušel jsem já blbec jiné domény než cz, které byli sice na rok levnější o 20 korun, ale na 10 let vycházely i na 12 tisíc.

2
Odkladiště / Dlouhodobá regitrace domény
« kdy: 09. 06. 2023, 15:34:30 »
Zdravím. Snad to nebude moc hloupý dotaz, ale po nějaké době googlení se nejsem schopen dopátrat odpovědi.

Jak je to z dlouhodobou registrací domény?
Všichni registrátoři mají uvedenou cenu na rok a co bude po roce, už jaksi nezmiňují. Chci se vyhnout situaci, kterou mám s autopojištěním a to měnit každý rok, jinak přeplácím.

Předem díky za vysvětlení.

3
Sítě / Re:Wireguard a vlastní DNS
« kdy: 19. 04. 2023, 13:39:52 »
Wireguard a DNS jsem řešil poslední dva dny, pro upřesnění ještě v kombinaci s Network managerem a wifi. Ntb málem letěl z okna. Nakonec jsem skončil u tohoto skriptu, který stačí přidat do PostUP a PostDOWN. Snad to někomu ušetří pár hezkých chvilek. Vím, je to prasárna, ale jak to udělat líp už mě opravdu nenapadá.

Kód: [Vybrat]
#!/bin/bash

if [ "$1" == "" ]; then
    echo 'missing flag, use -e or -d'
    exit 1
fi

DNS=192.168.5.5
Intefacename=wlo1
IterfaceID=$(nmcli con show | grep $Intefacename | cut -c 44- | awk '{print $1}')



while [ "$1" != "" ]; do
    case $1 in
    -e )
nmcli con modify $IterfaceID ipv4.dns $DNS && nmcli con modify $IterfaceID ipv4.ignore-auto-dns 'true' && systemctl restart network-manager.service
        ;;
    -d)
nmcli con modify $IterfaceID ipv4.dns '' && nmcli con modify $IterfaceID ipv4.ignore-auto-dns 'false' && systemctl restart network-manager.service
        ;;
    *)
        echo 'wrong flag, use -e or -d'
        exit 1
        ;;
    esac
    shift
done

4
Sítě / Re:Problém s lantencí (ztráta paketů) na veřejné IP
« kdy: 11. 01. 2021, 09:46:19 »
Dobrá rada jsem zase blíž k řešení. Server na některé requesty vůbec neodpovídá. Je možné, že je to někdy v nějakém cofigu omezené? Jak dál?

Btw co se gateway týče, nemám ji ve správě. Musel bych to řešit s providerem.

Kód: [Vybrat]
sudo tcpdump -ni ens192 icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ens192, link-type EN10MB (Ethernet), capture size 262144 bytes
08:41:42.204563 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 1, length 64
08:41:42.204664 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 1, length 64
08:41:43.391105 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 2, length 64
08:41:43.391189 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 2, length 64
08:41:44.471222 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 3, length 64
08:41:45.178873 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 4, length 64
08:41:45.178969 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 4, length 64
08:41:46.349173 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 5, length 64
08:41:47.201026 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 6, length 64
08:41:47.201117 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 6, length 64
08:41:48.181012 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 7, length 64
08:41:49.200990 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 8, length 64
08:41:49.201076 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 8, length 64
08:41:50.390776 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 9, length 64
08:41:51.220899 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 10, length 64
08:41:51.220987 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 10, length 64
08:41:52.221047 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 11, length 64
08:41:52.221134 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 11, length 64
08:41:53.230977 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 12, length 64
08:41:53.231058 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 12, length 64
08:41:54.401043 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 13, length 64
08:41:54.401127 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 13, length 64
08:41:55.221117 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 14, length 64
08:41:55.221200 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 14, length 64
08:41:56.240834 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 15, length 64
08:41:56.240914 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 15, length 64
08:41:57.240784 IP 37.188.138.185 > 83.208.220.156: ICMP echo request, id 1109, seq 16, length 64
08:41:57.240890 IP 83.208.220.156 > 37.188.138.185: ICMP echo reply, id 1109, seq 16, length 64
^C
28 packets captured
28 packets received by filter
0 packets dropped by kernel

5
Sítě / Re:Problém s lantencí (ztráta paketů) na veřejné IP
« kdy: 08. 01. 2021, 14:38:22 »
Pro TWVzc2E:
Tenhle příkaz neznám. Vrací mi toto:

Kód: [Vybrat]
sudo ethtool -K ens192 rx off tx off sg off tso off ufo off gso off gro off lro off 
Cannot change udp-fragmentation-offload
Pro cek_post.cz:
1. Virtuál, běží na ESXI.
2. V příloze.
3. Jednoduše 2xInterface, jeden vnitřní, jeden vnější
4. Ne komunikace ven je v pohodě.

Jinak kolize nehrozí.

6
Sítě / Re:Problém s lantencí (ztráta paketů) na veřejné IP
« kdy: 07. 01. 2021, 13:31:00 »
To mi moc nedává smysl. GW na našel PFsence je nastavená úplně stejně. Ten jsem tedy nenastavoval já, ale Ping na ní odpovídá normálně (83.208.220.155). Takže volat providera?



7
Sítě / Problém s lantencí (ztráta paketů) na veřejné IP
« kdy: 07. 01. 2021, 12:41:04 »
Zdavím,

   měl jsem porvé v životě tu čest souštět server s veřenou IP. Bohužel mám s tím v hlavičce uvedený problém. Zde jsou detaily verze serveru.

Kód: [Vybrat]
./+o+-
                  yyyyy- -yyyyyy+      OS: Ubuntu 20.04 focal
               ://+//////-yyyyyyo      Kernel: x86_64 Linux 5.4.0-59-generic
           .++ .:/++++++/-.+sss/`      Uptime: 50m
         .:++o:  /++++++++/:--:/-      Packages: 616
        o:+o+:++.`..```.-/oo+++++/     Shell: bash 5.0.17
       .:+o:+o/.          `+sssoo+/    Disk: 7.4G / 18G (44%)
  .++/+:+oo+o:`             /sssooo.   CPU: Intel Xeon E5410 @ 2.333GHz
 /+++//+:`oo+o               /::--:.   GPU: VMware SVGA II Adapter
 \+/+o+++`o++o               ++////.   RAM: 483MiB / 3936MiB
  .++.o+++oo+:`             /dddhhh. 
       .+.o+oo:.          `oddhhhh+   
        \+.++o+o``-````.:ohdhhhhh+   
         `:o+++ `ohhhhhhhhyo++os:     
           .o:`.syhhhhhhh/.oo++o`     
               /osyyyyyyo++ooo+++/   
                   ````` +oo+++o\:   
                          `oo++.
   Obě rozhraní běží bez problému. Přistup k DNS taky funguje. Jako firewall jsem použil UFW. Iptables jsem úplně vyčistil.

Kód: [Vybrat]
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host
       valid_lft forever preferred_lft forever
2: ens160: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:76:e4:0d brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.32/24 brd 192.168.100.255 scope global ens160
       valid_lft forever preferred_lft forever
3: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 00:0c:29:76:e4:17 brd ff:ff:ff:ff:ff:ff
    inet 83.208.220.156/29 brd 83.208.220.159 scope global ens192
       valid_lft forever preferred_lft forever   Ještě sem přivám obsah yaml souboru k netplan. Renderery jsem zkoušel oba, funguje mi jen ten nezakomentovaný.
Kód: [Vybrat]
network:
  version: 2
  renderer: networkd
#NetworkManager
  ethernets:
   ens192:
    dhcp4: no
    addresses: [83.208.220.156/29]
    gateway4: 83.208.220.153
    nameservers:
     addresses: [8.8.8.8]
Ping na danou IP se asi může každý zkusit sám. Předem děkuji za každou radu, google mi v tomto vůbec nepomohl.

8
Hardware / Re:Pokus o záchranu flashdisku
« kdy: 13. 12. 2020, 22:02:15 »
Here:

Kód: [Vybrat]
[74085.965320] usb 2-1.4: new SuperSpeed Gen 1 USB device number 29 using xhci_hcd
[74086.519825] usb 2-1.4: New USB device found, idVendor=125f, idProduct=db8a, bcdDevice= 1.00
[74086.519831] usb 2-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[74086.519834] usb 2-1.4: Product: Љ
[74086.519836] usb 2-1.4: Manufacturer: Љ
[74086.519838] usb 2-1.4: SerialNumber: Љ
[74086.522715] usb-storage 2-1.4:1.0: USB Mass Storage device detected
[74086.523183] scsi host0: usb-storage 2-1.4:1.0
[74087.529775] scsi 0:0:0:0: Direct-Access     XXXXXXXX U181CONTROLLER   0.00 PQ: 0 ANSI: 2
[74087.530387] sd 0:0:0:0: Attached scsi generic sg0 type 0
[74087.553506] sd 0:0:0:0: [sda] Attached SCSI removable disk
[74136.206032] usb 2-1.4: USB disconnect, device number 29

9
Hardware / Pokus o záchranu flashdisku
« kdy: 13. 12. 2020, 20:02:10 »
Pánové (a možná i dámy) zdravím,
abych přešel hned k věci. Leží my na stole flashdisk, ze kterého jsem se pokusil udělat bootovací. K tomuto účelu jsem využil přímo vnitřní utilitu mého Mintu (pravím na iso a vytvořit bootovací klíčenku). Bohužel při vytváření process jaksi zrmznul a mě po třech hodinách došla trpělivost. Ukončil jsem ho a flashdisk zůstal v prapodivném stavu. Přikládám nějaké výpisy z bashe. Příkazy pro ně jsem schrastil různě po interneru.

Kód: [Vybrat]
warezjoe@warezjoe-msi:~$ lsblk
NAME        MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
nvme0n1     259:0    0   477G  0 disk
├─nvme0n1p1 259:1    0   512M  0 part /boot/efi
└─nvme0n1p2 259:2    0 476,4G  0 part /run/timeshift/backup
warezjoe@warezjoe-msi:~$ lsusb
Bus 002 Device 026: ID 125f:db8a A-DATA Technology Co., Ltd.
Bus 002 Device 024: ID 0bda:8153 Realtek Semiconductor Corp. RTL8153 Gigabit Ethernet Adapter
Bus 002 Device 023: ID 2109:0815 VIA Labs, Inc. USB3.0 Hub             
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller
Bus 001 Device 026: ID 2109:8817 VIA Labs, Inc. USB2.0-CRW
Bus 001 Device 025: ID 18f8:0f99 [Maxxter] Optical gaming mouse
Bus 001 Device 024: ID 1a40:0101 Terminus Technology Inc. Hub
Bus 001 Device 023: ID 2109:2815 VIA Labs, Inc. USB2.0 Hub             
Bus 001 Device 004: ID 8087:0aaa Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
warezjoe@warezjoe-msi:~$ lspc
lspci     lspcmcia 
warezjoe@warezjoe-msi:~$ lspci
00:00.0 Host bridge: Intel Corporation Device 9b61 (rev 0c)
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics (rev 02)
00:12.0 Signal processing controller: Intel Corporation Comet Lake Thermal Subsytem
00:14.0 USB controller: Intel Corporation Device 02ed
00:14.2 RAM memory: Intel Corporation Device 02ef
00:14.3 Network controller: Intel Corporation Wireless-AC 9462
00:16.0 Communication controller: Intel Corporation Comet Lake Management Engine Interface
00:1d.0 PCI bridge: Intel Corporation Device 02b0 (rev f0)
00:1d.4 PCI bridge: Intel Corporation Device 02b4 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Device 0284
00:1f.3 Audio device: Intel Corporation Device 02c8
00:1f.4 SMBus: Intel Corporation Device 02a3
00:1f.5 Serial bus controller [0c80]: Intel Corporation Comet Lake SPI (flash) Controller
02:00.0 Non-Volatile memory controller: Sandisk Corp Device 5006
warezjoe@warezjoe-msi:~$ sudo dd if=/dev/zero of=/dev/sda
dd: otevření '/dev/sda' selhalo: Médium nebylo nalezeno
Někdo nějaká doporučení co dál?
 

Stran: [1]