Fryboyter

LAN Share - Spontan Dateien im LAN versenden

Vor ein paar Tagen habe ich mir auf mein Notebook etwas heruntergeladen, dass ich schlussendlich auf einem anderen Rechner benötigt habe. Um nicht wieder den Turnschuhadmin spielen zu müssen, habe ich mich gefragt welche Möglichkeiten es gibt Dateien möglichst ohne größeren Aufwand von Rechner X auf Rechner Y zu kopieren.

Der Bequemlichkeit halber bin ich bei LAN Share gelandet. Das Tool hat nur die Aufgabe Dateien bzw. ganze Verzeichnisse von einem Rechner zum anderen im LAN zu transferieren. Ideal wenn man nur alle paar Monate mal etwas spontan kopieren will.

LAN Share

Die grafische Oberfläche ist im Grunde idiotensicher. Man klickt links oben auf “Send” und wählt dann aus ob man Dateien oder Verzeichnisse versenden will. Dann wählt man die gewünschte Datei oder Verzeichnis aus und anschließend den Rechner der die Datei empfangen soll. Dort sollte logischerweise LAN Share auch gestartet sein. Abschließend klickt man auf “Send” und das war es schon.

OSBN | General

Borg-Repository auf rsync.net komplett prüfen

Für meine “Offside-Backups” benutze ich Borg und rsync.net. Heute wollte ich meine bei rsync.net gespeicherten Datensicherungen einmal komplett überprüfen.

borg check -v --verify-data XXXXX@ch-s010.rsync.net:MeinRepository

Leider bricht der Befehl schlussendlich immer mit der Fehlermeldung “Borg server is too old for scan. Required version 1.1.0b3” ab. Scheinbar verwendet rsync.net von Haus aus eine ältere Version von Borg. Auf der Internetseite kann man aber nachlesen, dass Version 0.29 und 1.x unterstützt werden. Also sollte es doch möglich sein, die aktuelle Version 1.x zu nutzen. Wie so oft hilft RTFM weiter. Es gibt die Variable BORG_REMOTE_PATH. Mit dieser kann man angeben welche Version von Borg auf dem Server verwendet werden soll. Im Fall von rsync.net muss man den bereits genannten Befehl wie folgt ändern, damit man Version 1.x von Borg verwendet.

borg check -v --verify-data --remote-path=/usr/local/bin/borg1/borg1  XXXXX@ch-s010.rsync.net:MeinRepository

Anstelle den Parameter –remote-path= zu verwenden, kann man das ganze auch allgemeiner mit “export BORG_REMOTE_PATH=/usr/local/bin/borg1/borg1” angeben. Für Scripte dürfte das die bessere Lösung darstellen.

Vor der Nutzung von –verify-data muss ich abschließend aber noch warnen. Hierbei wird sozusagen alles auf Herz und Nieren geprüft. Und das dauert. In dem Repository das ich für den Test verwendet habe, sind nur knapp 3 GB Daten vorhanden. Bis alles getestet worden ist, sind einige Stunden vergangen. Für allgemeine Prüfungen sollte man daher andere Einstellungen wählen.

OSBN | Linux

Windows leichter mit Syslinux starten

Wenn man mit dem Bootloader syslinux neben Linux auch Windows starten will, erfolgt dies bei Festplatten mit MBR (nicht GPT!) beispielsweise über folgenden Eintrag in der Datei /boot/syslinux/syslinux.cfg.

...
LABEL windows
    MENU LABEL Windows
    COM32 chain.c32
    APPEND hd0 3
...

Hd0 ist in diesem Fall die erste vom BIOS/UEFI erkannte Festplatte. Und 3 bezieht sich auf die dritte Partition auf dieser Festplatte. Was aber wenn man mehrere Festplatten installiert hat und Windows nicht auf der gleichen Platte wie Linux installiert ist? Man müsste herausfinden in welcher Reihenfolge das BIOS/UEFI die Festplatten erkennt. Hierbei muss man beachten, dass Festplatten ab 0 gezählt werden, Partitionen aber ab 1. Also warum das ganze nicht etwas einfacher lösen?

Mit dem Befehl “fdisk -l” lässt man sich zuerst die ganzen vorhandenen Festplatten anzeigen und sucht sich dann die Festplatte, auf der Windows installiert ist, heraus. Sollte man wissen auf welcher Festplatte Windows installiert ist, kann man sich diese auch direkt mit beispielsweise “fdisk -l /dev/sde” anzeigen lassen. Das sieht dann beispielsweise wie folgt aus.

Festplatte /dev/sde: 238,49 GiB, 256060514304 Bytes, 500118192 Sektoren
Festplattenmodell: Crucial_CT256MX1
Einheiten: Sektoren von 1 * 512 = 512 Bytes
Sektorgröße (logisch/physikalisch): 512 Bytes / 4096 Bytes
E/A-Größe (minimal/optimal): 4096 Bytes / 4096 Bytes
Festplattenbezeichnungstyp: dos
Festplattenbezeichner: 0x0000d958

Gerät      Boot    Anfang      Ende  Sektoren  Größe Kn Typ
/dev/sde1  *         2048    206847    204800   100M  7 HPFS/NTFS/exFAT
/dev/sde2          206848 499123111 498916264 237,9G  7 HPFS/NTFS/exFAT
/dev/sde3       499124224 500113407    989184   483M 27 Verst. NTFS WinRE

Wichtig ist hier im Grunde nur der Festplattenbezeichner. Diesen merken wir uns und ändern den Eintrag von Windows in der Konfigurationsdatei von syslinux wie folgt ab.

...
LABEL windows
    MENU LABEL Windows
    COM32 chain.c32
    APPEND mbr:0x0000d958
...

Mit diesem Eintrag sollte man Windows nun problemlose per Chainloading starten können.

OSBN | Linux

Dritte können nun Änderungen an meinen Artikeln vornehmen

Manchen Leuten ist scheinbar ab und zu sehr langweilig. Dieses Wochenende habe ich doch tatsächlich eine E-Mail mit Hinweisen auf den einen oder anderen Fehler in meinen Artikeln erhalten. Im Grunde waren es nur Rechtschreibfehler.

In der E-Mail wurde ich auf gefragt ob ich für solche Sachen nicht ein öffentlicht zugängliches Repository anbieten kann. Kann ich. Es ist unter https://github.com/Fryboyter/Hugo erreichbar.

Aber würde ich selbst einen Artikel lesen und dann das Repository aufrufen und die Datei suchen wen ich einen Fehler finden würde? Eher nicht. Daher habe ich nun einen Link unterhalb der jeweilige Artikelüberschrift eingebaut, der direkt auf die betreffende Datei bei Github verweist.

Als erstes habe ich hierfür in der Konfigurationsdatei von Hugo (config.toml) den Bereich [params] um einen Verweis auf das Repository eingetragen.

[params]
ghrepo = "https://github.com/Fryboyter/Hugo/"

Als nächstes habe ich das verwendete Theme (single.html und list.html) von fryboter.de wie folgt erweitert.

| <a href="{{.Site.Params.ghrepo}}edit/master/content/{{.File.Path}}" >Bei Github bearbeiten</a>

Hiermit wird das in der Datei conifg.toml hinterlegte Verweis auf das Respository genutzt. Dieser wird dann einfachum edit/master/content/ erweitert, da sich dieser Teil nicht ändert. Ganz am Schluss wird mit {{.File.Path}} auf die betreffende Datei verlinkt.

Im Grunde ist das mal wieder ziemlich simpel. Huge gefällt mir immer mehr.

OSBN | Allgemein

Bitbucket verabschiedet sich von Mercurial

Wer als Versionsverwaltung Mercurial verwendet und diese nicht selbst hosten will nutzt vermutlich meist das Angebot von Bitbucket.

Auf dem offiziellen Blog wurde nun bekannt gegeben, dass in einigen Monaten die Unterstützung für Mercurial eingestellt wird. Bitbucket setzt dann wie andere Anbieter (z. B. Github oder Gitlab) nur noch auf Git.

Ab dem 01. Februar 2020 kann man bei Bitbucket keine Mercurial-Repositories anlegen. Ab dem 01. Juni 2020 ist dann endgültig Schluss und die vorhandenen Repositories werden gelöscht.

Wer also Projekte bei Bitbucket hostet, sollte bis spätestens 31. Mai seine Daten sichern und sich nach einer Alternative umsehen.

Ich vermute die Entscheidung von Bitbucket wird dazu führen, dass einige Projekte nun zu Git wechseln.

Wer weiterhin Mercurial nutzen will, kann sich https://www.mercurial-scm.org/wiki/MercurialHosting ansehen. Dort werden einige alternative Anbieter (die mich auf den ersten Blick alle nicht beigeistern) aufgeführt.

Ebenfalls werden dort Möglichkeiten zu selber hosten genannt. Hier finde ich vor allem Heptapod interessant. Hierbei handelt es sich um einen Fork von Gitlab der Mercurial unterstützt. Zudem sind die Entwickler von Gitlab dem Fork postiv gesinnt und unterstützen die Entwicklung. Laut den Entwicklern ist Heptapod allerdings noch in einem frühen Entwicklungsphase. Wer also Mercurial für wichtige Projekte nutzt, sollte daher noch abwarten.

OSBN | Allgemein