Skip to content

Gitlab - Projekt verwalten

Linux
  • Und wieder was, was es zu entdecken gilt 🙂

    Ich habe eine Webseite, die ich mal ein wenig aufräumen möchte usw. Da wollen wir doch mal probieren, was man mit folgenden Webseiten anfangen kann. Da gibt es

    Früher musste man bezahlen um auf github ein privates Projekt zu verwalten, aber nach dem Kauf durch Microsoft ist ja etwas Bewegung in die Sache gekommen. Man kann mittlerweile auf beiden Diensten ein privates Projekt erstellen. Gut, dann mal ausprobieren. Für welchen Dienst ich mich hier jetzt entschieden habe, brauche ich wohl nicht extra erwähnen, oder? 🙂

    Zum Ausprobieren, muss mein Sicherungsordner auf meinem Haupt-PC herhalten, live wird das erst dann genutzt, wenn ich es verstanden habe 😉

    Ok, auf gitlab.com ein neues Projekt erstellen. Einen Project name eingeben, Visibilty Level wählen und unten bei Initialize repository... KEINEN Haken machen! Fertig!

    0d1fc8a3-0cb3-4733-9657-e7911c6baead-image.png

    Wir wechseln in den Ordner wo das Projekt liegt.

    Wichtig

    Wenn man Files im Projekt hat, die evt. sensible Informationen enthalten, dann legt man ein File mit dem Namen

    .gitignore
    

    an. Da schreibt man die Files oder Ordner rein, die nicht hochgeladen werden sollen. Ich habe da mal einen Upload Ordner reingemacht, den kann ich anderweitig sichern. Das würde hier nur stören, vermute ich zu mindestens im Moment.

    Init

    frank@frank-MS-7A34:~/Backup2$ git init
    Leeres Git-Repository in /home/frank/Backup2/.git/ initialisiert
    
    frank@frank-MS-7A34:~/Backup2$ git remote add origin git@gitlab.com:User/projekt.git
    
    frank@frank-MS-7A34:~/Backup2$ git add .
    

    Inital Commit

    frank@frank-MS-7A34:~/Backup2$ git commit -m "Initial commit"
    [master (Basis-Commit) 3ffbd45] Initial commit
     517 files changed, 204920 insertions(+)
     create mode 100644 .gitignore
     create mode 100644 2018.php
     create mode 100644 2019.php
     create mode 100644 abfrage.php
     create mode 100644 auswertung.php
    [gekürzt]
    

    Hochladen

    frank@frank-MS-7A34:~/Backup2$ git push -u origin master
    The authenticity of host 'gitlab.com (35.231.145.151)' can't be established.
    ECDSA key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
    Are you sure you want to continue connecting (yes/no)? yes
    Warning: Permanently added 'gitlab.com,35.231.145.151' (ECDSA) to the list of known hosts.
    Zähle Objekte: 455, Fertig.
    Delta compression using up to 12 threads.
    Komprimiere Objekte: 100% (450/450), Fertig.
    Schreibe Objekte: 100% (455/455), 1.84 MiB | 7.66 MiB/s, Fertig.
    Total 455 (delta 46), reused 0 (delta 0)
    remote: Resolving deltas: 100% (46/46), done.
    To gitlab.com:Bullet64/falschparker2.git
     * [new branch]      master -> master
    Branch 'master' folgt nun Remote-Branch 'master' von 'origin'.
    

    Danach sind alle Daten auf gitlab.com

    wird fortgesetzt....

  • Wenn Ihr mal folgendes Problem habt...

    root@server:/web# git push -u origin master
    git@gitlab.com: Permission denied (publickey).
    fatal: Konnte nicht vom Remote-Repository lesen.
    
    Bitte stellen Sie sicher, dass die korrekten Zugriffsberechtigungen bestehen
    und das Repository existiert.
    

    dann habt ihr keinen ssh Key erzeugt, oder bei gitlab.com abgelegt. Unter ~/.ssh nachsehen ob die Datei id_rsa.pub vorhanden ist. Wenn nicht dann

    ssh-keygen -t rsa
    

    ausführen. Und ganz wichtig, unter

    muss der Public-Key des Servers hinterlegt sein, sonst hat man logischerweise keinen Zugriff auf den Server.

    Danach sollte dann auch der Befehl

    git push -u origin master
    

    gehen.

    git push -u origin master
    Objekte aufzählen: 448, Fertig.
    Zähle Objekte: 100% (448/448), Fertig.
    Delta-Kompression verwendet bis zu 4 Threads.
    Komprimiere Objekte: 100% (443/443), Fertig.
    Schreibe Objekte: 100% (448/448), 1.86 MiB | 6.98 MiB/s, Fertig.
    Gesamt 448 (Delta 45), Wiederverwendet 0 (Delta 0)
    remote: Resolving deltas: 100% (45/45), done.
    To gitlab.com:xxxxxxxxxxxxxxxxxx.git
     * [new branch]      master -> master
    Branch 'master' folgt nun Remote-Branch 'master' von 'origin'.
    
  • Und mit git pull holt man dann die Änderungen usw.

     git pull
     remote: Enumerating objects: 11, done.
     remote: Counting objects: 100% (11/11), done.
     remote: Compressing objects: 100% (9/9), done.
     remote: Total 9 (delta 6), reused 0 (delta 0)
     Entpacke Objekte: 100% (9/9), Fertig.
     Von gitlab.com:xxxxxxxxxxxxxxxxxxxxxxxxxx
        44b219c..bd2c333  master     -> origin/master
     Aktualisiere 44b219c..bd2c333
     Fast-forward
      backend/gulpfile_DEL.js  | 135 ------------------------------------------------------------------------------------------------------------
      backend/logout.php_DEL   | 126 ----------------------------------------------------------------------------------------------------
      backend/package.json_DEL |  49 ---------------------------------------
      3 files changed, 310 deletions(-)
      delete mode 100644 backend/gulpfile_DEL.js
      delete mode 100644 backend/logout.php_DEL
      delete mode 100644 backend/package.json_DEL
    

  • MongoDB - Erste Erfahrungen

    Linux
    2
    0 Stimmen
    2 Beiträge
    59 Aufrufe
    FrankMF

    So frisch von der MongoDB Front und wieder viel gelernt, weil beim Üben macht man Fehler 🙂

    Oben war ja mongodump & mongorestore von der KI empfohlen. Hier das wie ich es gemacht habe.

    mongodump frank@redis-stack:~$ mongodump -u frank -p '<password>' --host 192.168.3.9 --authenticationDatabase admin -d portfolio -o mongodump/ 2024-04-06T09:29:25.174+0200 writing portfolio.stockList to mongodump/portfolio/stockList.bson 2024-04-06T09:29:25.175+0200 writing portfolio.users to mongodump/portfolio/users.bson 2024-04-06T09:29:25.175+0200 done dumping portfolio.stockList (8 documents) 2024-04-06T09:29:25.176+0200 writing portfolio.total_sum to mongodump/portfolio/total_sum.bson 2024-04-06T09:29:25.177+0200 done dumping portfolio.total_sum (1 document) 2024-04-06T09:29:25.177+0200 writing portfolio.old_total_sum to mongodump/portfolio/old_total_sum.bson 2024-04-06T09:29:25.177+0200 writing portfolio.stocks to mongodump/portfolio/stocks.bson 2024-04-06T09:29:25.177+0200 done dumping portfolio.users (4 documents) 2024-04-06T09:29:25.178+0200 writing portfolio.settings to mongodump/portfolio/settings.bson 2024-04-06T09:29:25.178+0200 done dumping portfolio.settings (1 document) 2024-04-06T09:29:25.179+0200 done dumping portfolio.old_total_sum (1 document) 2024-04-06T09:29:25.179+0200 done dumping portfolio.stocks (34 documents) mongorestore mongorestore -u frank -p '<password>' --host 192.168.3.9 --authenticationDatabase admin -d portfolio mongodump/meineDatenbank/

    Hier wird die Datensicherung mongodump/meineDatenbank/ in die neue Datenbank portfolio transferiert.

    Grund für das Ganze? Mich hatte der Datenbank Name meineDatenbank gestört.

    Benutzerrechte

    Jetzt der Teil wo man schnell was falsch machen kann 🙂 Ich hatte also die neue Datenbank, konnte sie aber nicht lesen. Fehlten halt die Rechte. Ich hatte dann so was hier gemacht.

    db.updateUser("frank", { roles: [ { role: "readWrite", db: "meineDatenbank" }, { role: "readWrite", db: "portfolio" }]})

    Ging auch prima, kam ein ok zurück. Nun das Problem, ich hatte beim Einrichten, den User frank als admin benutzt. Durch den oben abgesetzten Befehl (frank ist ja admin), wurden die neuen Rechte gesetzt und die Rechte als Admin entzogen!! Das war jetzt nicht wirklich das was ich gebrauchen konnte. LOL

    Ich hatte jetzt keine Kontrolle mehr über die DB. Das war aber nicht so wirklich kompliziert, das wieder zu ändern. Die Authentication temporär abstellen. Also /etc/mongod.conf editieren und

    #security: security.authorization: enabled

    eben mal auskommentieren. Den Daemon neustarten und anmelden an der DB.

    mongosh --host 192.168.3.9

    Danach neuen User anlegen

    db.createUser({ user: "<name>", pwd: "<password>", roles: [ { role: "userAdminAnyDatabase", db: "admin" } ] })

    mongod.conf wieder ändern und neustarten. Danach hat man wieder eine DB mit Authentifizierung und einen neuen Admin. Ich bin diesmal, man lernt ja, anders vorgegangen. Es gibt nun einen Admin für die DB und einen User zum Benutzen der Datenbanken! So wie man es auch auf einem produktiven System auch machen würde. Wenn ich jetzt mal was an den Benutzerrechten des Users ändere, kann mir das mit dem Admin nicht mehr passieren. Hoffe ich 🙂

  • Manjaro - KDE Plasma 6

    Linux
    1
    0 Stimmen
    1 Beiträge
    182 Aufrufe
    Niemand hat geantwortet
  • KDE neon 6.0

    Linux
    2
    0 Stimmen
    2 Beiträge
    105 Aufrufe
    FrankMF

    Heute mal in die bestehende Installation meine Intel ARC A580 GPU eingesteckt. Wollte mal schauen ob das gut klappt. Da die Treiber ja im Kernel vorhanden sind, habe ich keinerlei Probleme erwartet. Und so war es auch. Neustart und fertig. Im BIOS natürlich vorher umgestellt, das sie auch benutzt wird, habe ja einen AMD Prozessor mit eingebauter GPU im CPU-Sockel stecken.

    Screenshot_20240303_101728.png

    Die Wechselfunktion (oben links in der Ecke) um die virtuellen Desktops zu wechseln und zu bearbeiten ist richtig gut geworden.

    Screenshot_20240303_101809.png

    Und auch ein Ärgernis auf meiner KDE Plasma Installation scheint weg zu sein. Wenn ich ein Programm zur Arbeitsfläche hinzugefügt hatte, wurde die Position immer irgendwann zurückgesetzt. Beispiel, Icon des Programmes rechts unten abgelegt. Irgendwann tauchte es dann in der normalen Ansicht (alphabetisch) sortiert, links oben, wieder auf. Sehr nerviger Bug.

  • Debian Bookworm 12.5 released

    Linux
    3
    0 Stimmen
    3 Beiträge
    103 Aufrufe
    FrankMF

    Und hier taucht es dann auf -> https://www.debian.org/News/2024/20240210

  • Flatpak - Signal

    Linux
    1
    0 Stimmen
    1 Beiträge
    66 Aufrufe
    Niemand hat geantwortet
  • KDE Plasma 6 - RC1

    Linux
    3
    0 Stimmen
    3 Beiträge
    103 Aufrufe
    FrankMF

    Heute die letzte Unstable Edition von KDE Neon installiert. Es gab folgende Version.

    neon-unstable-20240201-2132.iso

    Meldet sich bei mir immer noch nur als DEV Version und nicht als RC2 🤔 Wenn einer einen Tipp für mich hat....

    Der Installer soll mich ja nicht mehr interessieren, aber mir ist aufgefallen, das er jetzt den Standort hinbekommt.

    Ansonsten läuft es soweit rund. Habt ihr schon mal einen Firefox ohne Addblocker benutzt? Grausam! Kann mir gar nicht vorstellen, so was in meinem Leben nochmal zu benutzen.

  • 0 Stimmen
    1 Beiträge
    143 Aufrufe
    Niemand hat geantwortet
  • Semaphore - Die API

    Verschoben Ansible
    2
    0 Stimmen
    2 Beiträge
    127 Aufrufe
    FrankMF

    Ich hasse schlecht lesbaren Code, scheint man sich bei Python so anzugewöhnen. Habe da nochmal was mit der langen Zeile getestet.

    stages: - deploy deploy: stage: deploy script: # $SEMAPHORE_API_TOKEN is stored in gitlab Settings/ CI/CD / Variables - >- curl -v XPOST -H 'Content-Type: application/json' -H 'Accept: application/json' -H "Authorization: Bearer $SEMAPHORE_API_TOKEN " -d '{"template_id": 2}' https://<DOMAIN>/api/project/2/tasks only: - master # Specify the branch to trigger the pipeline (adjust as needed)

    Hier noch was Dr. ChatGPT dazu schreibt

    631de9d4-b04d-4043-bfff-c5f2d1b6eea7-grafik.png

    Erledigt - läuft 🙂 Und verstanden habe ich es auch.