Problem bei GIT installation...

[stoned49th]

Hallo,

ich versuche gerade auf meiner DS211 git zum laufen zu bekommen...aber irgendetwas geht bei der installation schief, und meine erfahrung mit
Linux ist leider noch recht beschränkt...

Folgenden stand habe ich gerade:

- IPKG läuft soweit, auch nach dem DSM4.0 update (opt über symlink "eingebunden")

- Bei der installation über iPKG kommt folgendes:

ipkg install git
Installing git (1.7.10-1) to root...
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/git_1.7.10-1_arm.ipk
package git suggests installing git-manpages
ipkg: Cannot link from ./opt/libexec/git-core/git to './opt/bin/git-receive-pack': Invalid cross-device link
ipkg: Cannot link from ./opt/libexec/git-core/git-cvsserver to './opt/bin/git-cvsserver': Invalid cross-device link
ipkg: Cannot link from ./opt/libexec/git-core/git-shell to './opt/bin/git-shell': Invalid cross-device link
ipkg: Cannot link from ./opt/libexec/git-core/git-upload-pack to './opt/bin/git-upload-pack': Invalid cross-device link
Configuring git
Successfully terminated.

Danach:

> git             
-ash: git: not found

wobei:

> git-upload-pack
usage: git upload-pack [--strict] [--timeout=<n>] <dir>

> git-shell
fatal: Interactive git shell is not enabled.
hint: ~/git-shell-commands should exist and have read and execute access.

Bin gerade echt ratlos...wahrscheinlich ist es wieder was total banales und ich steig einfach nicht durch...

So long,
Lukas

 

[goetz]

Hallo,

ipkg: Cannot link from ./opt/libexec/git-core/git to './opt/bin/git-receive-pack': Invalid cross-device link 
ipkg: Cannot link from ./opt/libexec/git-core/git-cvsserver to './opt/bin/git-cvsserver': Invalid cross-device link 
ipkg: Cannot link from ./opt/libexec/git-core/git-shell to './opt/bin/git-shell': Invalid cross-device link 
ipkg: Cannot link from ./opt/libexec/git-core/git-upload-pack to './opt/bin/git-upload-pack': Invalid cross-device link

was ist denn in /opt/bin und /opt/libexec/git-core an git Programmen enthalten?

Gruß Götz

 

[stoned49th]

was ist denn in /opt/bin und /opt/libexec/git-core an git Programmen enthalten?

Gruß Götz

 ls /opt/bin | grep git
git
git-cvsserver
git-receive-pack
git-shell
git-upload-archive
git-upload-pack

ls /opt/libexec/git-core/ | grep git
git-add
git-add--interactive
git-am
git-annotate
git-apply
git-archimport
git-archive
git-bisect
git-bisect--helper
git-blame
git-branch
git-bundle
git-cat-file
git-check-attr
git-check-ref-format
git-checkout
git-checkout-index
git-cherry
git-cherry-pick
git-clean
git-clone
git-commit
git-commit-tree
git-config
git-count-objects
git-credential-cache
git-credential-cache--daemon
git-credential-store
git-cvsexportcommit
git-cvsimport
git-daemon
git-describe
git-diff
git-diff-files
git-diff-index
git-diff-tree
git-difftool
git-difftool--helper
git-fast-export
git-fast-import
git-fetch
git-fetch-pack
git-filter-branch
git-fmt-merge-msg
git-for-each-ref
git-format-patch
git-fsck
git-fsck-objects
git-gc
git-get-tar-commit-id
git-grep
git-hash-object
git-help
git-http-backend
git-http-fetch
git-http-push
git-imap-send
git-index-pack
git-init
git-init-db
git-instaweb
git-log
git-lost-found
git-ls-files
git-ls-remote
git-ls-tree
git-mailinfo
git-mailsplit
git-merge
git-merge-base
git-merge-file
git-merge-index
git-merge-octopus
git-merge-one-file
git-merge-ours
git-merge-recursive
git-merge-resolve
git-merge-subtree
git-merge-tree
git-mergetool
git-mergetool--lib
git-mktag
git-mktree
git-mv
git-name-rev
git-notes
git-pack-objects
git-pack-redundant
git-pack-refs
git-parse-remote
git-patch-id
git-peek-remote
git-prune
git-prune-packed
git-pull
git-push
git-quiltimport
git-read-tree
git-rebase
git-rebase--am
git-rebase--interactive
git-rebase--merge
git-receive-pack
git-reflog
git-relink
git-remote
git-remote-ext
git-remote-fd
git-remote-ftp
git-remote-ftps
git-remote-http
git-remote-https
git-remote-testgit
git-repack
git-replace
git-repo-config
git-request-pull
git-rerere
git-reset
git-rev-list
git-rev-parse
git-revert
git-rm
git-send-email
git-send-pack
git-sh-i18n
git-sh-i18n--envsubst
git-sh-setup
git-shortlog
git-show
git-show-branch
git-show-index
git-show-ref
git-stage
git-stash
git-status
git-stripspace
git-submodule
git-svn
git-symbolic-ref
git-tag
git-tar-tree
git-unpack-file
git-unpack-objects
git-update-index
git-update-ref
git-update-server-info
git-upload-archive
git-var
git-verify-pack
git-verify-tag
git-web--browse
git-whatchanged
git-write-tree

Hast du eine Idee an was es liegen könnte?

So long,
Lukas

 

[stoned49th]

könnte es vielleicht an den PATH geschichten liegen die sich seit DSM4.0 anscheinend geändert haben und deshalb etwas schiefläuft? Irgendwie hab ich da so ein gefühl, weiß aber nicht so recht wo ich schauen soll/muss/darf/kann...


EDIT: Funktioniert Habe gerade alles nochmal gelöscht (optware, opt, etc.), ipkg neu aufgesetzt und den link neu gesetzt. Scheinbar hatte ich dort irgendeinen sehr intelligenten Fehler gemacht. Und siehe da, kaum macht mans richtig, funktionierts auch Jetzt kanns losgehen mit dem Sparkleshare


So long,
Lukas

 

[TobiasReich]

Bei mir gehts nicht

Sorry, aber bei mir ist trotz des Neuinstallierens nach dem Reboot alles weg.

ls /opt/bin | grep git
bringt gar nichts

Liegt das ggf. daran, dass ich optware über einen Link verknüpft habe:
ln -s /volume1/@optware/* /opt/

Das Kommando: ls -la /opt/bin gibt:
lrwxrwxrwx 1 root root 21 Jun 25 18:29 /opt/bin -> /volume1/@optware/bin

und wenn ich hier ls -la abfrage erhalte ich:

lrwxrwxrwx 1 root root 23 Jun 25 22:40 git -> ../libexec/git-core/git
-rwxr-xr-x 1 root root 120932 Jun 24 09:09 git-cvsserver
-rwxr-xr-x 2 root root 1158864 Jun 24 09:09 git-receive-pack
-rwxr-xr-x 1 root root 467808 Jun 24 09:09 git-shell
-rwxr-xr-x 2 root root 1158864 Jun 24 09:09 git-upload-archive
-rwxr-xr-x 1 root root 484376 Jun 24 09:09 git-upload-pack

es ist also alles irgendwie da.

Auch bei
ls /opt/libexec/git-core/ | grep git
sind all die Dateien gefunden.

Dennoch habe ich beim Nutzen von Git folgende Fehlermeldung:
Synchronize: Local changes could not be pushed.
'master' rejected (non-fast-forward)
error: cannot run unpack-objects: No such file or directory
error: cannot run gc: No such file or directory
error: unpack failed: unpack-objects abnormal exit error failed to push ...

Hat da irgendwer Erfahrungen mit? Woran liegt das? Ich dachte an fehlenden / nicht gefundenen Dateien, aber da sind sie ja offenbar.
Liegt das am PATH eventuell??

Ich hoffe, ihr könnt mir helfen,
Tobias

 

[stoned49th]

Ja, könnte am PATH liegen...hast du die PATH zeilen im Root wie in der IPKG anleitung angegeben auskommentiert?

Wenn ja, ich hatte nach der gitolite installation mit dem neuen user "git" auch probleme mit ssh. UserEnvironments mit eigenem Path haben das problem dann gelöst....wobei ich hier speziell noch das /bin im homefolder einbinden musste, ist aber gitolite spezifisch... den Symlink würde ich auch einfach mit

ln -s /volume1/@optware /opt

setzen.

> cat /volume1/homes/git/.ssh/environment

PATH=/opt/bin:/opt/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/syno/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin:/volume1/homes/git/bin

kannst du denn nachdem du den symlink gesetzt hast für diese session das "git" kommando ausführen?

So long,
Lukas

 

[TobiasReich]

Danke für die schnelle Antwort.

Den Link für Optware (ln -s /volume1/@optware /opt) habe ich bereits gesetzt, damit auch IPKG und Co. bei mir laufen.
Wenn ich git als Kommando angebe klappt das soweit auch. Allerdings hat git ja auch im opt/bin eine Verknüpfung nach
"../libexec/git-core/git"
Während "unpack-objects" usw. da ja keine haben und folglich auch nicht gefunden werden.

Die Idee mit dem PATH würde ich nun gerne verfolgen. Allerdings gibt es bei mir
"/volume1/homes/git/.ssh/environment"
leider nicht.
In dem .ssh Ordner befindet sich lediglich die Datei: "authorized_keys" für die Anmeldung.
Ich dachte, ich müsste das in der "/root/.profile" (vom Admin) machen. Immerhin habe ich hier ja auch wie im Wiki die PATH: Zeile auskommentiert. War das nun falsch?

Dort steht, man solle die beiden Zeilen ab V4 auskommentieren. Und sie sehen jetzt so aus:

#PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/
#export PATH

Also auch einige Pfadangaben weniger als bei Dir. Daran könnte es natürlich liegen, ich habe mich nur nicht getraut, daran herum zu spielen, zumal die ja angeblich nicht mehr in Benutzung sein soll.

Soweit dazu. Was genau sollte ich jetzt also machen bitte?

Vielen Dank schonmal,
Tobias


P.S.
Auch mit Deinen ganzen PATH Angaben funktioniert es leider nicht. Ich habe mal nach Deinem Vorbild den Gituser Eintrag ans Ende angehangen und beide Zeilen wieder einkommentiert:

PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/syno/sbin:/usr/syno/bin:/usr/local/sbin:/usr/local/bin:/opt/bin:/opt/sbin:/usr/bin:/volume1/homes/Gituser/bin:/opt/libexec/git-core
export PATH

Git hat trotzdem immernoch das selbe Problem:
error: cannot run unpack-objects: No such file or directory
Aber wie gesagt, ich weiß auch nicht, ob es das Richtige ist, wenn ich das für den Admin mache, Git aber mit dem Gituser benutze. Nur der hat ja kein .profile :-S

 

[stoned49th]

Öhm, du darfst das ja auch nicht für root tun... die zeilen müssen auskommentiert bleiben, theoretisch kann man sie auch einkommentieren, wenn man sie modifiziert, aber dazu kenn ich die IPKG inits nicht gut genug.

Sowas meinte ich: http://www.netexpertise.eu/en/ssh/environment-variables-and-ssh.html

Grob gesagt wird damit für diesen User beim Login ein anderer Path für die Shell-Session gesetzt. Falls du den User eh nur für Git verwendest und deine Key-Auth funktioniert, könntest du das ganze Problem auch über die Authorized Keys umgehen indem du die bekannte command="" Syntax benutzt und dort direkt auf die git-shell gehst, ähnlich wie gitolite das tut. Eine restricted shell ist für sowas eh sicherheitstechnisch besser, hab ich mir für svn auch so eingerichtet. Solltest du mal mehr user haben (wovon bei einem VCS ja auszugehen ist) kannst du so auch einfach fremden usern einen sehr eingeschränkten zugriff geben. Hier für git ohne gitolite http://superuser.com/questions/299927/can-you-specify-git-shell-in-ssh-authorized-keys-to-restrict-access-to-only-git

Edit: Du könntest auch wie hier: http://stackoverflow.com/questions/6081147/how-to-create-a-restricted-ssh-account-for-a-git-repository direkt auf die git-shell gehen.

# gitolite start
command="/volume1/homes/git/gitolite/src/gitolite-shell %GITUSERNAME%",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-rsa *** keycomment
# gitolite end

Für die user env musst du einfach in der sshd_config "PermitUserEnvironment yes" setzen und dann die environment in den jeweiligen .ssh-ordner packen. Chown für deinen user nicht vergessen, bei den rechten reicht 644 vollkommen. hier nochmal meine env, wobei du den gitolite pfad nicht brauchst (der letzte eintrag):

> cat /volume1/homes/git/.ssh/environment
PATH=/opt/bin:/opt/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/syno/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin:/volume1/homes/git/bin

 

[TobiasReich]

Ah, okay, dann haben wir uns misverstanden. Mit einkommentiertem PATH gibts nämlich eh mehr Probleme als Lösungen. IPKG selbst geht beispielsweise auch nicht mehr:

> ipkg update
Downloading http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/Packages.gz
An error ocurred, return value: 1.
Collected errors:
ipkg_download: ERROR: Command failed with return value 41: `wget --passive-ftp -q -P /opt/ipkg-lR3JZ3 http://ipkg.nslu2-linux.org/feeds/optware/cs08q1armel/cross/unstable/Packages.gz'

Die Idee, die ganze Geschichte mit der Shell usw. zu ändern könnte gut sein, aber Zugriffe und Rechte sind mir erst einmal fürs Erste nebensächlich. Ich würde es gerne erst einmal zum Laufen bringen, bevor ich mir über mehrere Benutzer Gedanken mache. In ver DSM V3 ging alles eigentlich ganz gut und ich wundere mich halt, weswegen es jetzt diese Probleme gibt.

Ich habe eben nochmal git neu installiert. Vielleichts sind diese Fehlermeldungen hier jetzt auch von Bedeutung:
ipkg: Cannot link from ./opt/libexec/git-core/git to './opt/bin/git-receive-pack': Invalid cross-device link
ipkg: Cannot link from ./opt/libexec/git-core/git-cvsserver to './opt/bin/git-cvsserver': Invalid cross-device link
ipkg: Cannot link from ./opt/libexec/git-core/git-shell to './opt/bin/git-shell': Invalid cross-device link
ipkg: Cannot link from ./opt/libexec/git-core/git-upload-pack to './opt/bin/git-upload-pack': Invalid cross-device link

Das habe ich früher einfach mit einem Link gelöst. Andere Seiten empfehlen das über den PATH zu machen:
http://www.wonko.de/2010/04/set-up-git-on-synology-nas.html

Aber wie erwähnt, ich habe für meinen Gituser gar keine Datei:
~/.ssh/environment

Ist das jetzt normal oder habe ich da etwas falsch gemacht? Bei mir gibts nur die authorized_keys aber die nutze ich im Moment eh nicht, weil ich das erst einmal zum laufen bekommen möchte...

 

[stoned49th]

Hm, also ich würde jetzt mal

1. PATH auskommentiert lassen (falls nicht schon geschehen)
2. GIT nochmal komplett runter. Manuell überprüfen ob nochwas da ist, wenn ja, weg damit. Auch evtl. vorhandene links löschen.
3. /opt komplett aushängen bzw. link löschen
4. reboot
5. /opt neu verlinken mit ln -s /volume1/@optware /opt
6. git neu installieren
7. commands für root testen
8. reboot
9. nochmal für root testen
10. env für user setzen
11. als gituser einloggen und sehen obs geht

Die environment erstellt sich nicht selbst...das musst du genauso manuell tun wie bei der keyfile, oder bash-profilen. Einfach mit "touch" die file erstellen und dann mit dem editor aufmachen, oder aus einem editor raus dahinspeichern

Achso, sollten die git-executeables nicht da liegen wo sie hinsollen, verlinke die einfach. Aber nicht auf opt, sondern im @optware, dann bleibt das auch bei einem Update deiner DS bestehen. Sonst musst du das danach wieder einbinden. Ich muss nur noch opt wieder einhängen

Edit: So sollte das aussehen:

> ll /volume1/@optware/bin/ | grep git
lrwxrwxrwx  1 root root      23 Jun 21 18:17 git -> ../libexec/git-core/git
-rwxr-xr-x  2 root root  120930 Jun 18 21:57 git-cvsserver
-rwxr-xr-x  3 root root 1158860 Jun 18 21:57 git-receive-pack
-rwxr-xr-x  2 root root  467808 Jun 18 21:57 git-shell
-rwxr-xr-x  3 root root 1158860 Jun 18 21:57 git-upload-archive
-rwxr-xr-x  2 root root  484376 Jun 18 21:57 git-upload-pack
lrwxrwxrwx  1 root root      31 Apr 22 14:43 gitolite -> /volume1/homes/git/bin/gitolite

> ll /volume1/@optware/libexec/ | grep git
drwxr-xr-x  3 root root   4096 Jun 21 18:17 git-core

 

[TobiasReich]

Okay, danke. Also alles neu ist schon mal ein Anfang. Bis Punkt 9 war alles soweit ja ganz einfach und scheint zu gehen.
Auch die Files sind (mit außnahme von Gitolite) wie bei Dir.
Ich weiß nur nicht genau, welche Datei ich jetzt erstellen soll bzw. wo.
Meinst Du eine ~/.ssh/environment Datei in meinem Gituser?
Und was genau muss ich dann dort alles hineinschreiben?

Wenn ich Dich richtig verstanden habe, sollte ich da
PATH=/opt/bin:/opt/sbin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/syno/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/syno/bin:/usr/syno/sbin:/usr/local/bin:/usr/local/sbin:/volume1/homes/Gituser/bin
reinschreiben, aber macht das dann nicht wieder das selbe Problem wie mit dem PATH?

Und die sshd_config brauche ich doch nur fürs ssh anmelden, oder? Also ist das erst einmal nicht, woran es liegen könnte, richtig? Immerhin kann ich mich ja übers Passwort bei Git anmelden.

Danke nochmal für die ganze Hilfe. Ich weiß, irgendwie bin ich da nicht der schlaueste. :-/

Tobias

--

Hm, also ich würde jetzt mal

1. PATH auskommentiert lassen (falls nicht schon geschehen)
2. GIT nochmal komplett runter. Manuell überprüfen ob nochwas da ist, wenn ja, weg damit. Auch evtl. vorhandene links löschen.
3. /opt komplett aushängen bzw. link löschen
4. reboot
5. /opt neu verlinken mit ln -s /volume1/@optware /opt
6. git neu installieren
7. commands für root testen
8. reboot
9. nochmal für root testen
10. env für user setzen
11. als gituser einloggen und sehen obs geht

Die environment erstellt sich nicht selbst...das musst du genauso manuell tun wie bei der keyfile, oder bash-profilen. Einfach mit "touch" die file erstellen und dann mit dem editor aufmachen, oder aus einem editor raus dahinspeichern

Achso, sollten die git-executeables nicht da liegen wo sie hinsollen, verlinke die einfach. Aber nicht auf opt, sondern im @optware, dann bleibt das auch bei einem Update deiner DS bestehen. Sonst musst du das danach wieder einbinden. Ich muss nur noch opt wieder einhängen

Edit: So sollte das aussehen:

> ll /volume1/@optware/bin/ | grep git
lrwxrwxrwx  1 root root      23 Jun 21 18:17 git -> ../libexec/git-core/git
-rwxr-xr-x  2 root root  120930 Jun 18 21:57 git-cvsserver
-rwxr-xr-x  3 root root 1158860 Jun 18 21:57 git-receive-pack
-rwxr-xr-x  2 root root  467808 Jun 18 21:57 git-shell
-rwxr-xr-x  3 root root 1158860 Jun 18 21:57 git-upload-archive
-rwxr-xr-x  2 root root  484376 Jun 18 21:57 git-upload-pack
lrwxrwxrwx  1 root root      31 Apr 22 14:43 gitolite -> /volume1/homes/git/bin/gitolite

> ll /volume1/@optware/libexec/ | grep git
drwxr-xr-x  3 root root   4096 Jun 21 18:17 git-core

 

[TobiasReich]

Mal ne blöde Frage noch dazu. Da auf einmal wieder git (und wieder ipkg) nicht gefunden werden kann (ich habe neu gestartet, aber das kanns doch nicht sein, oder)
Ich wollte gerade für git noch wie hier (http://www.fabforge.ch/content/git-auf-einer-synology) beschrieben den Link setzen:
ln -s /opt/bin/git-upload-pack /usr/bin/git-upload-pack
da sehe ich, dass in /opt/ gar kein /bin Ordner existiert.
Hier ist lediglich ein Link auf @optware und dort ist dann /bin drin
der Link oben nach /opt/bin kann also gar nicht funktionieren. Das führt mich zu der Frage, ob ich ggf. ohnehin mit dem Optware Krams irgendwas falsch gemacht habe. Soll ich vielleicht einfachmal @optware und /opt/ einfach ganz und gar löschen und alles nochmal neu machen? Ich bin etwas verzweifelt... :-/

 

[stoned49th]

?!

vorsicht mit der linux syntax, /opt ist nicht das gleiche wie /opt/ .Vielleicht ist da beim symlink was schief gelaufen. Sollte es funktionieren, müsste ein "ls" in /opt genau das gleiche bringen wie in /volume1/@optware. Mit ls -la hingehen siehst du dann das alles nur gelinkt ist.

Daher nochmal "rm /opt" und nochmal "ln -s /volume1/@optware /opt".

 

[TobiasReich]

Hm, okay, das ist sehr gut zu wissen.
Also ist das "Richtige" @optware, ja?

Bei mir siehts so aus:

Station> cd /volume1/@optware/
Station> ls -la
drwxr-xr-x 11 root root 4096 Jun 26 13:45 .
drwxr-xr-x 18 root root 4096 Jun 26 14:07 ..
lrwxrwxrwx 1 root root 17 Jun 26 13:43 @optware -> /volume1/@optware
drwxr-xr-x 2 root root 4096 Jun 26 13:41 bin
drwxr-xr-x 5 root root 4096 Jun 26 13:41 etc
drwxr-xr-x 2 root root 4096 Jun 26 13:41 include
drwxr-xr-x 5 root root 4096 Jun 26 13:41 lib
drwxr-xr-x 3 root root 4096 Jun 26 13:41 libexec
drwxr-xr-x 4 root root 4096 Jun 26 13:41 man
drwxr-xr-x 9 root root 4096 Jun 26 13:41 share
drwxr-xr-t 2 root root 4096 Feb 15 22:52 tmp
drwxr-xr-x 3 root root 4096 Jun 26 13:39 var
Station> cd /opt
Station> ls -la
drwxr-xr-x 8 root root 4096 Jun 26 13:34 .
drwxr-xr-x 23 root root 4096 Jun 26 14:07 ..
lrwxrwxrwx 1 root root 17 Jun 25 18:25 @optware -> /volume1/@optware
drwxr-xr-x 3 root root 4096 Jun 25 21:45 doc
drwxr-xr-x 4 root root 4096 Jun 26 13:32 include
drwx------ 2 root root 4096 Jun 25 18:33 ipkg-RllxQJ
drwxr-xr-x 3 root root 4096 Jun 24 09:09 libexec
drwxr-xr-x 4 root root 4096 Jun 25 21:45 local
drwxr-xr-x 2 root root 4096 Jun 25 21:44 sbin
Station>

Also irgendwie nicht wirklich was verlinkt. Oder ist das der Normalzustand. Ich werde mal /opt löschen und alles neu machen (inklusive IPKG). Hoffentlich klappt das.
Ich dachte immer /opt/ wäre das gleiche.
Vielleicht hilft das ja...
Danke!