Posts by DCSH

    Ich habe dazu noch diese Links hier gefunden:
    http://blog.unixweb.de/vga-und…m-raspberry-pi-betreiben/
    https://raspberrypi.stackexcha…/multiple-display-screens


    Beide sind so ein bisschen verwirrend in Bezug auf Anzeige-Erweiterung und suggerieren eher, dass es ginge. Ich bin da auch eher skeptisch und denke, dass jar Recht hat.


    Zusätzlicher Hinweis: Das von Dir verlinkte Tutorial schildert den umgekehrten Fall, dass Du per RDP auf den Pi zugreifst, nicht vom Pi auf einen Terminalserver.

    Eigentlich wird die Angabe AUTOSTART in /etc/default/openvpn nur benötigt, wenn Du die Verbindungen manuell oder gar nicht automatisch starten lassen willst, da andernfalls init.d meines Wissens nach automatisch alle .conf-Files abarbeitet.


    Code
    # Start only these VPNs automatically via init script.
    # Allowed values are "all", "none" or space separated list of
    # names of the VPNs. If empty, "all" is assumed.


    Kommentier's also mal aus und schau, was passiert.

    Klingt mehr nach nem Routing-Problem. Ich gehe davon aus, dass Du den VNC-Server auf dem pi per interner IP ansprichst? Evtl. besteht genau dieser IP-Bereich auch im WLAN bei Deinem Kumpel und er sucht nur lokal. Eventuell musst Du Deiner VPN-App mitteilen, dass sämtlicher Verkehr über das VPN gehen soll. Ansonsten zeig uns doch mal die Server- und Client config files.

    Requirements und Ahnung sind hier gleichermaßen offensichtlich nicht vorhanden, weswegen ich screen-Session-Basteleien auch für völlig unrealistisch halte, wenn schon das mit dem IRC nicht klappt.


    Ein "Aufploppen" von Nachrichten kann man damit nicht hinbekommen, aber einfach alle immer ans Netz und dann bei Bedarf draufgucken, so haben wir das früher auch immer gemacht. Kurze Einleitung gibts zB unter http://irc.fu-berlin.de/einfuehrung.html


    Ihr braucht zum Server zusätzlich noch jeweils einen IRC-Client, einloggen (ggf. klären, wer von wo auf den IRC-Server zugreifen kann, Du schreibst ja "alle auf einem Server", aber das klingt wenig plausibel - da ist die Kristallkugel beschlagen), Raum aufmachen mit /join #wasauchimmer, drinbleiben, schreiben, fertig.


    Der eigene Jabber-Server ist in meinen Augen eine machbare Alternative. Wie die Clients auf dem pi laufen kann ich da nicht beurteilen...

    Wenn es um sowas wie das "net send" damals bei Windows geht, das halte ich weder für zweckmäßig noch für praktikabel.


    Internen IRC-Server auf einem der Raspis aufsetzen, alle da einloggen, fertig. Das ist wenigstens ein ordentlicher Chat und bietet noch wesentlich mehr Funktionalität. Ich sehe keinen speziellen Bedarf für ein dezentralisiertes System, wie bislang vorgeschlagen...

    Danke erstmal für die Antwort. Am sinnvollsten wäre das am Hardware-Router, den ich aber nicht entsprechend konfigurieren kann... vom raspi aus ist es eher hinderlich, weil man per PXE ja auch mal Notfall-Rettungssysteme booten könnte, wo es immer schlecht ist, erstmal die MAC zu suchen... für die "bekannten" Rechner werde ich das aber erstmal so machen. Die Routen dann aber direkt auf den pi, oder (siehe Frage, was für PXE in den "next-server" muss)? Wie bekomme ich die denn von dort aus wieder über den Router zum WAN?

    Liebes Forum,


    ich wollte auf meinem pi einen PXE-Server aufsetzen, um auf mehreren Rechner einfach mal Live-Images von Distributionen durchtesten zu können und diese ggf. auch gleich zu installieren.


    Ich bin nach Georgs Anleitung vorgegangen:
    http://www.gtkdb.de/index_36_1974.html


    Erstes Problem: DHCP.


    Die dhcp.conf habe ich so angepasst:


    Leider verträgt sich der DHCP-Server im pi dann (offenbar) nicht mit dem DHCP-Server vom Router. Jedenfalls wunderte ich mich, warum ich von Windows-Laptop aus nicht mehr ins Internet kam, tracert stieg mit obskurer Fehlermeldung aus. Mit allen anderen Geräten ging es noch (vermutlich war der lease beim Laptop gerade abgelaufen).


    Mir fiel dann nur in den Einstellungen am PC auf, dass der Domain-Name "raspberry.lan" übergeben wurde (IP war aber die reguläre, die vom Router regelmäßig auch vergeben wird). DHCP-Server deaktiviert, alles ging wieder. Irgendwo muss also ein Haken in der Konfiguration sein... erster Gedanke: als next-server sollte für die PXE-Geschichte sicherlich die IP des raspis rein (bei mir *.105), nicht des Routers, korrekt? Aber löst das auch das Problem, dass ich keine Route ins Internet mehr finde? Oder muss ich den DHCP im Router sowieso abschalten?


    2. Problem: NFS


    Nach meinen Erkenntnissen benötigt man das NFS, um nach dem TFTP-versendeten Menü an die Dateien der eigentlichen Images ranzukommen. Offenbar gibt es da auch andere Möglichkeiten als method, aber ich habe dazu nichts gefunden, weil der Tenor eigentlich ist "Nimm NFS, das geht schnell und ist einfach".


    Der raspi will akut nicht den nfs-kernel-server starten. Er meldet immer:

    Code
    $ sudo service nfs-kernel-server start
    [warn] Not starting NFS kernel daemon: no support in current kernel. ... (warning).


    Kernel-Version:

    Code
    $ cat /proc/version
    Linux version 3.6.11+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #474 PREEMPT Thu Jun 13 17:14:42 BST 2013


    Meines Wissens nach sollte dieser Kernel den NFS-Support schon drinhaben... ich habe ein bisschen Bammel davon, den Kernel zu updaten, weil der raspi derzeit so elementare Aufgaben übernimmt, dass ich ohne ihn ziemlich alt aussehen würde.


    Ich will möglichst unkompliziert eine Möglichkeit haben, die Dateien für den PXE-Boot auch zu übergeben. Gibt es da Alternativen?


    Beste Grüße
    Daniel
    [/code]

    Neben der obligatorischen Beipflichtung für ruedigerp:


    Wie sieht's aus mit VPN ins Heimnetzwerk und quasi von dort aus interner Zugriff auf squid? Sicherer und trotzdem komfortabel, wäre meine bevorzugte Lösung. Ansonsten scheint die ACL-Regel und http_access grundsätzlich stimmig, allerdings habe ich noch nie so kurze und uneingeschränkte Regeln gesehen.


    EDIT: Mögliche Fehlerquelle:
    "Die Authentifizierung funktioniert nur mit einem Proxy, der normal angesprochen wird. Richtet man Squid als transparenten Proxy ein, so ist eine Authentifizierung nicht möglich, da der Proxy ja nicht direkt vom Client aus angesprochen wird."
    Quelle: http://wiki.ubuntuusers.de/Squid


    Klingt plausibel. Von außen müsstest Du den ja auch nicht transparent machen...

    Okay, OpenELEC also, das ist auch noch ne wichtige Information, ober stand noch raspbian.


    Der Zugriff auf Deine Videos, von denen Du oben gesprochen hattest, war der auch über OpenELEC und Samba oder war das ganz anders?


    Poste mal bitte Den Share aus Deiner smb.conf und Deine /etc/fstab (ich gehe davon aus, dass Du die HDD darüber gemounted hast, oder macht das OpenELEC anders?). Entweder ist die Festplatte read-only gemounted, oder es gibt keine Schreibrechte für den Pfad. In dem Tutorial sind public=yes und writable=yes drin, was nicht sonderlich sicher ist und auch eventuell mit den Berechtigungen des Dateisystems kollidiert. Ich kenne mich da leider mit der Benutzerverwaltung unter OpenELEC auch überhaupt nicht aus, da kann bestimmt jemand anders weiterhelfen mit den angefordeten Informationen.

    Samba ist wirklich exakt das, was Du suchst - Dateizugriff auf externe Medien über das Netzwerk. Belies Dich einfach nochmal dazu. Falls Du den smbd tatsächlich schon laufen hast - ich meine, der ist bei XBMC vorinstalliert -, kann es sein, dass Du bislang entweder nicht über die Windows-Netzwerkumgebung darauf zugreifst, sondern irgendwie anders (Media-Player?), oder aber, dass einfach der Speicherort noch nicht als SMB-Share freigegeben ist.


    HDD an raspi anschließen, mounten, (smb installieren), als smb-share einrichten, fertig. Massenhaft Tutorials für Raspbian hier im Forum.


    Ich bin mir ziemlich sicher dass ich das ! mit drin hatte, ich hab die Regel jetzt erstmal einfach wieder entfernt.


    Nur mal aus Interesse, für was setzt du den Rechner ein?


    Und nach dem Entfernen funktioniert es wieder? Dann war entweder das ! nicht mit drin, oder der IP-Bereich, aus dem Dein SSH-Zugriff tatsächlich erfolgt, lag nicht im 192.168.178er Bereich?


    Einsatz meines pi - nichts spektakuläres dabei:
    - hosted OwnCloud (allerdings mit nginx statt apache)
    - dient als OpenVPN-Server, damit ich im Ausland und auf Dienstreise eine sichere, verschlüsselte Internetverbindung nutzen kann
    - dient als squid-Proxy für meine Android-Endgeräte im WLAN und filtert dabei zuverlässig Werbung raus
    - dient als NAS und lässt mich über Samba externe Festplatten ansteuern
    - bringt einen alten USB-Laserdrucker via CUPS ins WLAN
    - erledigt nachts stromsparend große/langwierige Downloads via wget-Dateiliste

    Lars: Das ! ist aber mit drin? Da Du "auch" geschrieben hast, gehe ich davon aus, dass Du es sowohl von außen als auch von innen probiert hast.


    Nur, um hier trotz OT mal ruedigerp zu unterstützen: JEDER Rechner, der von außen erreichbar ist, gehört vernünftig abgesichert. Dazu gehört in der Tat, Privatrechner oder nicht, ein schlüssiges Sicherheitskonzept. Ja, jeder Internetnutzer weltweit ist potenziell gefährdet, ich habe keine Ahnung warum Du das per se ablehnst...


    Alles was vorgeschlagen wurde, ist sinnvoll, richtig und mit verhältnismäßig geringem Aufwand umsetzbar. Portwechsel-Obscurity bringt keinen Schutz im eigentlichen Sinne und gehört definitiv NICHT zu den Vorschlägen, die bei konkreten Nachfragen zum Hardening überhaupt erwähnt werden sollten, da es unerfahrene Nutzer in tatsächlich nicht vorhandener Sicherheit wiegen kann.


    Ich habe übrigens auch am Privatrechner und auch auf Nicht-Standard-Ports monatlich eine niedrige vierstellige Anzahl an Zugriffsversuchen. Böse Zungen behaupten: Wer in den Logs keine auffälligen Einträge in großer Menge sieht, der sieht aus einem ganz bestimmten Grund keine ;)

    Ich habe auch spontan an Diaspora gedacht, ohne aber genau zu wissen, ob es für alle Deine Vorstellungen Plug-Ins bietet.

    Es gibt auch noch für überschaubares Geld Dongles für nen Fernseher, per USB, HDMI oder sonstwas... ich finde das auch eine gute Alternative für Senioren, weil auch die Hemmschwelle wegen des bekannten "Endgerätes" geringer ist. Da läuft meist ein Android drauf, was für die Zwecke auch gut genügen sollte.

    Liebe Kollegen,


    ich bin ja hier schon seit einiger Zeit unterwegs und berate in Sachen owncloud.


    Nachdem ich mit der Funktionalität der owncloud-Installation soweit zufrieden bin, will ich das ganze auch redundant auslegen, um endgültig auf mein eigenes Backup-System umzusteigen. Hintergrund ist vor allem, dass ich von Dropbox aus Datenschutzgründen weg will, obwohl ich dort aus verschiedenen Gründen > 60 GB kostenlosen Space habe.


    Vorteil einer "Cloud-Lösung" gegenüber sonstiger Dateiverwaltung (SMB/WebDAV/SFTP):
    - Ein Client kümmert sich anlassbezogen um den Upload veränderter Dateien, ohne dass etwas nötig ist. Das schafft ein cronjob nicht in vergleichbarer Qualität und das ist auch weder durch meine Frau noch von ihrem Windows-Rechner aus userfreundlich zu bewerkstelligen.
    - Gleichzeitig habe ich die Daten auch ohne Netzwerkverbindung auf allen Geräten aktuell, wenn die Synchronisation vorschriftsmäßig läuft und bin so auch unterwegs gut ausgestattet


    Der große Vorteil externer Anbieter ist eben:
    - Einbruch, Feuer, Hardwareausfall zu Hause interessiert mich das nicht, wenn die Daten bei einem Hoster liegen
    - Ausrichtung auf Versioning, Uptime und Redundanz


    Deshalb mein Projekt:


    1.) Wenn der Client von owncloud sich mit meiner Installation verträgt, werden alle Daten auf dem System gleichzeitig auf die owncloud-Installation auf dem pi gespiegelt.
    -> automatisch, abhängig vom Client:
    - owncloud-eigener Client für Desktop/Laptop,
    - foldersync (turnusbasiert) via WebDAV vom Android-Telefon/-Tablet.


    2.) Dort soll ein Teil der Daten (die GB an Fotos sind einfach zu groß) automatisch in einen verschlüsselten Container gepackt werden.
    ->
    - cronjob einmal täglich oder öfter
    - mount der owncloud-Installation via WebDAV oder direkter Zugriff aufs FS
    - truecrypt oder ähnlicher Container, ca. 4 GB (dazu gab's schon was im Forum)
    Problem: Passwortübergabe? Speicherung auf pi?


    3.) Der verschlüsselte Container wird dann vom pi mit der Dropbox synchronisiert
    ->
    - cronjob einmal täglich des nachts
    - Dropbox-API existiert und kann angesprochen werden, dazu gab's schon was hier im Forum
    - bei Beibehaltung des Zeitpunkts des Containers wird der Container nur segmentiell hochgeladen, so dass nicht jedesmal der volle Upload anfällt - so jedenfalls beim Windows-Client, das muss für die API geprüft werden.


    4.) Optional:
    ->
    Zur Streuung das ganze auch noch mit anderen Anbietern, dort wäre dann zu prüfen, ob auch ein segmentieller Upload möglich ist. Da die meisten anderen aber WebDAV anbieten, soll er notfalls die ganze Nacht per cronjob rödeln, ohne dass ich mich um irgendeine API kümmern muss.


    Problematisch ist halt, dass jemand mit dem Einkassieren der SD-Karte im pi ziemlich viele Zugangsdaten gleichzeitig abgreifen könnte, die Daten mal außen vor gelassen, weil die sowieso unverschlüsselt auf der Platte liegen. Hat jemand Anregungen oder eine Hilfestellung zu dem Projekt?