Skip to content

Debian Buster 10 Release

Linux
3 1 463
  • Am heutigen Tage soll ja Debian Buster 10 released werden. Da ich mir vorgenommen habe, das heute zu testen und es wohl noch was dauert, habe ich kurzerhand zum RC3 gegriffen. Da ich das schon mal getestet hatte, mit wenig Erfolg, war ich auf eine Menge Probleme gefasst.

    Also, das Image auf den USB-Stick und den Rechner damit gebootet. Die Debian Installation macht man ja schon fast im Schlaf 😉 USB-Stick raus und neugestartet. Aber, was ist das? Der Login Bildschirm läßt sich nicht vernünftig bedienen, der Mauszeiger springt nur völlig träge über den Bildschirm. 😞

    Nachdem ich die Installation ausgeschlossen hatte, musste es am Grafiktreiber liegen. So ungewöhnlich finde ich mein Setup gar nicht. Also gehe ich davon aus, das die installierten Treiber Schrott sind. Da müssen jetzt die NVidia Treiber drauf.

    Beim erneuten Starten den abgesicherten Modus aufgerufen. Danach nach dieser Anleitung vorgehen.

    Das so durchgeführt und bei der Installation meckert er über den vorhandenen noveau Treiber. Der ist aber nach einem Neustart Geschichte. OK, alles so installiert und neugestartet. Und, schwupps läuft der Desktop (Gnome).

    Bildschirmfoto vom 2019-07-06 19-55-29.png

    Manche Dinge nerven, auch noch nach vielen Jahren Linux.

    Installation

    apt -y install nvidia-detect
    

    Danach

    frank@debian:~$ nvidia-detect
    Detected NVIDIA GPUs:
    1c:00.0 VGA compatible controller [0300]: NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] [10de:1c82] (rev a1)
    
    Checking card:  NVIDIA Corporation GP107 [GeForce GTX 1050 Ti] (rev a1)
    Your card is supported by the default drivers and legacy driver series 390.
    It is recommended to install the
        nvidia-driver
    package.
    

    nvidia installieren

    apt install nvidia-driver
    

    Danach einmal neustarten

    systemctl reboot
    

    Update

    Buster 10 released https://www.debian.org/News/2019/20190706

  • Mein WLan zickt rum und ließ sich nicht einschalten. Da such ich mit der Fehlermeldung im Netz und stolper über mein eigenes Forum 😂

    https://forum.frank-mankel.org/topic/532/atomicpi-wlan-geschwindigkeit/4

    Die Interface Namen waren mal wieder die Ursache.

    GRUB_CMDLINE_LINUX_DEFAULT="net.ifnames=0"
    

    Ob das ein Bug von Debian Buster 10 ist? Ich weiß es nicht, aber vielleicht hilft es irgend einer verzweifelten Seele da draußen 😉

  • Da man ja beim Login auswählen kann, mit was die Session startet, war ich doch jetzt etwas neugierig was überhaupt läuft.

    IMG_20190707_092217.jpg

    frank@debian:~$ echo $WAYLAND_DISPLAY
    
    frank@debian:~$ loginctl
    SESSION  UID USER       SEAT  TTY 
          7 1000 frank      seat0 tty2
         c1  116 Debian-gdm seat0 tty1
    
    2 sessions listed.
    frank@debian:~$ loginctl show-session c1 -p Type
    Type=x11
    frank@debian:~$ loginctl show-session c1 
    Id=c1
    User=116
    Name=Debian-gdm
    Timestamp=Sat 2019-07-06 22:43:34 CEST
    TimestampMonotonic=30094837
    VTNr=1
    Seat=seat0
    TTY=tty1
    Remote=no
    Service=gdm-launch-environment
    Scope=session-c1.scope
    Leader=1015
    Audit=4294967295
    Type=x11
    Class=greeter
    Active=no
    State=online
    IdleHint=yes
    IdleSinceHint=1562446130937731
    IdleSinceHintMonotonic=346278596
    LockedHint=yes
    

    Die Installation der Nvidia Treiber macht da wohl einen x11 Desktop raus. Aber auch nicht weiter schlimm, der Wayland lief ja hier überhaupt nicht. Würde mich aber über interessante Links zum Thema freuen 😉

  • 0 Stimmen
    3 Beiträge
    56 Aufrufe
    frankm@nrw.socialF
    @tux "Im November 2023 kaufte die Kiteworks Europe AG ownCloud – eine Tochter des milliardenschweren amerikanischen Security-Anbieters Kiteworks LLC. "Quelle: https://www.heise.de/news/Ex-ownCloud-Devs-suchen-Neustart-bei-OpenCloud-Owncloud-Besitzer-will-klagen-10253188.htmlFür mich Grund genug, die Finger davon zu lassen.
  • OpenCloud - Docker Compose Hetzner VM

    Verschoben OpenCloud opencloud linux docker
    2
    2
    0 Stimmen
    2 Beiträge
    162 Aufrufe
    FrankMF
    Ich habe mich nochmal mit verschiedenen Aspekten der produktiven Installation beschäftigt. Auch ein wenig die KI befragt und dann ein paar Änderungen vorgenommen. Was hatte mich gestört? Traefik lief als root. Um das zu ändern, habe ich das docker-compose.yml angepasst. Ich habe auch gleich mal auf die aktuelle Version angepasst. services: traefik: image: traefik:v3.4.1 #3.3.1 container_name: traefik user: "1000:1001" # 1000 = dockeruser, 1001=docker group cap_add: - NET_BIND_SERVICE # erlaubt Ports <1024 restart: always networks: - opencloud-net ports: - "80:80" - "443:443" volumes: - ./certs:/certs # bind-mount acme.json - /var/run/docker.sock:/var/run/docker.sock:ro command: - "--log.level=${TRAEFIK_LOG_LEVEL:-ERROR}" # Let's Encrypt HTTP-01 Challenge - "--certificatesResolvers.http.acme.email=${TRAEFIK_ACME_MAIL:-example@example.org}" - "--certificatesResolvers.http.acme.storage=/certs/acme.json" - "--certificatesResolvers.http.acme.httpChallenge.entryPoint=http" - "--certificatesResolvers.http.acme.caserver=${TRAEFIK_ACME_CASERVER:-https://acme-v02.api.letsencrypt.org/directory}" # Dashboard - "--api.dashboard=true" # Entrypoints - "--entryPoints.http.address=:80" - "--entryPoints.http.http.redirections.entryPoint.to=https" - "--entryPoints.http.http.redirections.entryPoint.scheme=https" - "--entryPoints.https.address=:443" - "--entryPoints.https.transport.respondingTimeouts.readTimeout=12h" - "--entryPoints.https.transport.respondingTimeouts.writeTimeout=12h" - "--entryPoints.https.transport.respondingTimeouts.idleTimeout=3m" # Docker Provider - "--providers.docker.endpoint=unix:///var/run/docker.sock" - "--providers.docker.exposedByDefault=false" # Access Log - "--accessLog=true" - "--accessLog.format=json" - "--accessLog.fields.headers.names.X-Request-Id=keep" labels: - "traefik.enable=${TRAEFIK_DASHBOARD:-false}" - "traefik.http.middlewares.traefik-auth.basicauth.users=${TRAEFIK_BASIC_AUTH_USERS:-admin:$$apr1$$4vqie50r$$YQAmQdtmz5n9rEALhxJ4l.}" - "traefik.http.routers.traefik.entrypoints=https" - "traefik.http.routers.traefik.rule=Host(`${TRAEFIK_DOMAIN:-traefik.opencloud.test}`)" - "traefik.http.routers.traefik.middlewares=traefik-auth" - "traefik.http.routers.traefik.tls.certresolver=http" - "traefik.http.routers.traefik.service=api@internal" networks: opencloud-net: volumes: {} Und hierzu - ./certs:/certs # bind-mount acme.json brauch es noch ein paar Anpassungen auf dem Host, also im Verzeichnis von wo wir deployen mit dem dockeruser! mkdir -p ./certs touch ./certs/acme.json chmod 600 ./certs/acme.json chown 1000:1000 ./certs/acme.json # UID muss mit docker-compose user übereinstimmen Das klappt jetzt hier einwandfrei. dockeruser@opencloud:~/opencloud/deployments/examples/opencloud_full$ docker exec -it traefik id uid=1000 gid=1001 groups=1001 Sieht soweit gut aus Die KI meint noch das hier Wenn du maximale Sicherheit willst, kannst du langfristig docker-socket-proxy einsetzen. Er erlaubt Traefik nur lesenden Zugriff auf die Container-API: → Projektseite: Tecnativa/docker-socket-proxy Das muss ich aber erst noch sacken lassen und mich etwas zu einlesen.
  • MongoDB Compass

    Linux mongodb flatpak linux
    1
    3
    0 Stimmen
    1 Beiträge
    250 Aufrufe
    Niemand hat geantwortet
  • MSI B650 Tomahawk WiFi

    Allgemeine Diskussionen msi b650 am5 amd linux
    5
    5
    0 Stimmen
    5 Beiträge
    2k Aufrufe
    FrankMF
    @kiwilog Danke für die Antwort. Ich habe mittlerweile ein ASUS Rog Strix B650E-F Gaming Wifi. Auch dieses Board hatte Probleme. Ich habe dann den RAM ausgetauscht und jetzt funktioniert es. Das MSI Board liegt hier aber noch, so das ich deinen Tipp da mal testen kann. Das wartet aber noch auf einen AMD Ryzen 9000 Als Fazit, die AM5 Plattform scheint sehr empfindlich zu sein.
  • OpenWRT - Zonen

    Verschoben OpenWRT & Ubiquiti ER-X openwrt linux
    2
    3
    0 Stimmen
    2 Beiträge
    691 Aufrufe
    FrankMF
    Es ist was heller geworden [image: 1610188645165-7b86e97c-31a5-44b6-809f-25d9d1c2ee4a-image.png] Die besagte Forward Regel [image: 1610188840619-zonen.png] Diese Forward Regel zieht erst dann, wenn es mehrere Interfaces in einer Zone gibt. Aus der Doku INPUT rules for a zone describe what happens to traffic trying to reach the router itself through an interface in that zone. OUTPUT rules for a zone describe what happens to traffic originating from the router itself going through an interface in that zone. FORWARD rules for a zone describe what happens to traffic passing between different interfaces belonging in the same zone. Das heisst nun, das ein Forwarding zwischen zwei Zonen immer eine spezifische Regel unter Traffic Rules benötigt. Forwarding between zones always requires a specific rule. Somit ist ein Forwarding zwischen zwei Zonen in den Standard Einstellungen nicht erlaubt. Das kann ich hier auch so bestätigen. Das ist ja auch das was ich mit meiner "DMZ"-Zone erreichen möchte. Kein Zugriff auf LAN. Unter Zone ⇒ Forwardings kann man jetzt sehen, das das Forwarding von LAN in Richtung WAN und DMZ erlaubt ist. WAN ist logisch, sonst komme ich ja nicht ins Internet. DMZ habe ich eingestellt, damit ich auch Teilnehmer im DMZ Netz erreichen kann, wenn ich da mal ran muss. [image: 1610189307657-8a548c29-8bc5-4074-8099-66460bcea9a8-image.png] Stelle ich das jetzt so ein. [image: 1610189398985-dca8b393-f613-4cab-a377-ffbc2bb8ddf5-image.png] Dann kann ich von der DMZ Zone aus das LAN erreichen. Aha, so langsam verstehe ich Quelle: https://forum.openwrt.org/t/firewall-zones-and-settings/84369
  • ROCKPro64 - 0.9.16 mit Kernel 5.6 auf PCIe NVMe SSD

    ROCKPro64 linux rockpro64
    1
    0 Stimmen
    1 Beiträge
    401 Aufrufe
    Niemand hat geantwortet
  • IPv6 und Subnetze

    Linux linux ipv6
    1
    0 Stimmen
    1 Beiträge
    252 Aufrufe
    Niemand hat geantwortet
  • Liste von Linuxbefehlen

    Angeheftet Linux linux
    5
    1
    0 Stimmen
    5 Beiträge
    1k Aufrufe
    FrankMF
    Kurzer IPv6 Ping, ohne viel Tipparbeit root@:~# ping 2600:: PING 2600::(2600::) 56 data bytes 64 bytes from 2600::: icmp_seq=1 ttl=55 time=14.9 ms 64 bytes from 2600::: icmp_seq=2 ttl=55 time=13.0 ms 64 bytes from 2600::: icmp_seq=3 ttl=55 time=15.9 ms