GAG18 fail (was: Wie würdet ihr das Netzwerk gestalten?)

2019-04-25 Diskussionsfäden Christian Perle
Hallo Stefan,

On Thu, Apr 25, 2019 at 21:27:57 +0200, Stefan Engelhardt wrote:

> gestern war ich vor der Tür des GAG18 um die Angelegenheit mit euch
> persönlich zu besprechen, wenn dafür Zeit verfügbar gewesen wäre.
> 
> Leider bin ich nur auf 3 Andere gestoßen die sagten, dass das GAG18
> um 20 Uhr zugeschlossen wurde und die Leute richtung Club11 gelaufen
> sind. Dort war aber auch kein Linuxer zu finden.

Wir haben bis ca. 20:20 Uhr vor dem GAG18 gewartet, um eventuelle
LUG-Interessenten dort abzufangen. Dann sind wir aufgebrochen, allerdings
zur Torwirtschaft, nicht zum Club11.

> Bei meinem ersten Versuch hatte ich das GAG nicht gefunden, weil ich
> in das "Wohnhaus" reingangen war. Diesmal wußte ich wo die Tür ist,
> aber trotz Termin keiner da. Bis jetzt scheint die LUG Dresden nicht
> sehr professionel.

Es ist sicherlich nicht die Schuld der LUG und es kotzt mich auch ziemlich
an, wenn das GAG18 ohne Vorankuendigung Mittwochs geschlossen bleibt :-/

Gruss,
  Christian
-- 
Christian Perlechris AT linuxinfotag.de
010111  http://chris.silmor.de/
101010  LinuxGuitarKitesBicyclesBeerPizzaRaytracing



Re: Wie würdet ihr das Netzwerk gestalten?

2019-04-25 Diskussionsfäden Stefan Engelhardt
Hallo Kristian,

gestern war ich vor der Tür des GAG18 um die Angelegenheit mit euch
persönlich zu besprechen, wenn dafür Zeit verfügbar gewesen wäre. Leider
bin ich nur auf 3 Andere gestoßen die sagten, dass das GAG18 um 20 Uhr
zugeschlossen wurde und die Leute richtung Club11 gelaufen sind. Dort war
aber auch kein Linuxer zu finden.
Bei meinem ersten Versuch hatte ich das GAG nicht gefunden, weil ich in das
"Wohnhaus" reingangen war. Diesmal wußte ich wo die Tür ist, aber trotz
Termin keiner da. Bis jetzt scheint die LUG Dresden nicht sehr
professionel. Da bin ich wohl von Frankfurt und Hanau etwas zu verwöhnt :)

Die Gedanken wollte ich mit euch durchsprechen und wenn machbar auch
umsetzen. Je früher für alles eine Lösung gefunden ist und einfach
umsetzbar ist, umso besser.

Was jeder Kunde haben dürfte ist ein Internetzugang. Hier sehe ich also
zuerst mal zum Beispiel den Router der sich aufhängen könnte. Da ich ein
fauler Sack bin, würde ich einen Raspberry laufen lassen wollen, der den
Router kontrolliert. Diesen bei Bedarf neustartet. Eventuell die
Internetverbindung neu herstellt und was halt sonst noch so geht. Welche
Fritzbox-Alternative gibt es denn, die sich automatisiert steuern läßt?

Gruß Stefan


Am Di., 23. Apr. 2019 um 08:37 Uhr schrieb Kristian Rink :

> Hallo Stefan;
>
> wie konkret ist das Projekt, das Du da umreißt? Noch Ideenstudie, oder
> schon näher der Planung/Realisierung?
>
>
> >
> > Verständnisfragen:
> > 1.) Der Raspberry hat ja eine IP-Adresse des Kanzlei-Netzwerkes. Wenn
> > er nachts bei der Datenbank die Änderungen nachfragt, muss er dann
> > selbstständig eine VPN-Verbindung aufbauen um so relativ sicher zur
> > Datenbank zu kommen oder muss die Datenbank fürs Internet freigemacht
> > werden, sodas ein Hacker auch an die Datenbank kommt?
> >
>
> Mit gegenwärtigem Stand würde ich das Ganze vermutlich andersherum
> aufziehen: Ich würde die Infrastruktur (Storage, Administrations-
> Systeme, ...) in einem kontrollierten Rechenzentrum vor Ort
> unterbringen und der Kanzlei und den dortigen Arbeitsplätzen Zugriff
> über ein VPN dorthin einrichten, auch um die ganze Lösung robuster
> betreiben zu können, Stichwort "Private Cloud". Das hätte verschiedene
> Vorteile auch im Blick auf weitergehende Ideen, die Du noch umrissen
> hast (etwa: FTP-Server oder zusätzliche Dienste). Fraglich allerdings,
> ob das für die Zielkunden gewünscht ist. Eigene Erfahrung vor Jahren:
> IT für Rechtsanwälte ist dort ein Thema für sich...
>
>
> > 2.) Was ist, wenn das Portfolio der Dienstleistungen erweitert wird?
> > Beispielsweise kann die Kanzlei nun einen FTP-Server mieten. Wie
> > aktualisiert sich der Raspberry beim Kunden? Also wie kommt das
> > Installationsscript für den FTP-Server automatisch auf den Raspberry?
> >
>
> Ideen dazu:
>
> - Setze ein eigenes .deb-Repository auf und lass die Linux-
> Paketverwaltung auf dem Raspberry die Installation übernehmen.
>
> - Schiebe Deine Scripts, Konfig-Vorlagen, ... in dedizierte git-
> Repositories unter Deiner Kontrolle, die sich die Systeme bedarfsweise
> clonen.
>
> - Nutze ein Management-Tool wie puppet, chef oder ansible, das
> vermutlich relativ viel der notwendigen Funktionen out of the box kann,
> aber dann irgendwie mit der Self Service - Idee, die Dir vorschwebt,
> verheiratet werden müsste.
>
>
>
> > 3.) Kann man überhaupt mit einer Programmiersprache eine Fritzbox
> > oder NAS wie Synology "programmieren / einrichten / verwalten"?
> >
>
> Bei Fritz!Box und Co. weiß ich es nicht; die NAS-Systeme haben im
> Allgemeinen irgendwelche APIs, um $DINGE damit zu tun - ich vermag
> allerdings nicht zu beurteilen, ob die leistungsfähig genug für das
> sind, was Du hier willst / brauchst. Vielleicht bietet die Entwickler-
> Übersicht bei Synology[1] hier mehr Erleuchtung. Insgesamt würde ich
> aber hier versuchen, diese Aufgaben (ganz gleich ob auf Seite des
> Kunden oder im RZ) mit einem Linux-Server abzubilden.
>
>
> Viele Grüße,
> Kristian
>
>
>
> [1]https://www.synology.com/de-de/support/developer#tool
>
>
>


Re: Self-Hosting vs. Cloud

2019-04-25 Diskussionsfäden Jens
Zu diesem Thema hat der Chef von Univention Peter Ganten einen 
interessanten Artikel mit dem Titel "Uns droht ein technikzentriertes 
Mittelalter" verfasst.


https://www.faz.net/aktuell/wirtschaft/diginomics/digitale-souveraenitaet-statt-digitalem-mittelalter-16021367.html?GEPC=s3=0x1c8ff7be24a093599949e463cd8d6d44

Viele Grüße

Jens




Re: Alternative zu github: Weitere sterbende Trends

2019-04-25 Diskussionsfäden mail
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Am Mittwoch, den 24.04.2019, 18:09 +0200 schrieb Thomas Güttler:
> Microsoft ein üblichen Verdächtiger? Für mich ist MS deutlich auf dem
> Abwertstrend.
> 
> In den Mobilphone-Markt kommen sie nicht mehr.
> 
> Für's Office interessieren sich auch immer weniger. In der Schule
> (bei meinem Sohn)
> wird LibreOffice verwendet. Und so braucht es nicht mehr lange und
> die nächste
> Generation bringt das in die Firmen.

Also ein Abwärtstrend sieht für mich aber anders aus [1]. Das liegt
auch nicht an Office. Ein paar Pfennige machen sie noch durch ihre
Knebelverträge mit Behörden [2], aber das große Geld kommt heute von
Azure [3]. Damit gehört Microsoft sehr wohl zu einem der mächtigsten
Akteure der Weltwirtschaft. Wenn alles was im Internet passiert durch
deine Infrastruktur läuft, brauchst du dir um deine Zukunft keine
Sorgen machen. Amazon verdient sein Geld auch nicht mehr mit Büchern.

> Für mich ist es der bequemste Weg.

Klar ist es das. Das ist ja das Geschäftsmodell von Github. Genau wie
das von Apple, Google, Facebook, usw…

> Welche Alternative zu github siehst du für die wenigen Bytes hier?

Nun, offenbar betreibst du ja einen Server bei Hetzner. Was spricht
dagegen, dort ne Textdatei (bzw HTML) hochzuladen? Feedback per E-Mail.

Wenns unbedingt Git sein soll, legst du dort mit `git init --bare` ein
Repo an und verlinkst es. Solls ein bißchen ergonomischer sein? Setz
ein Gitea auf ne Subdomain. Lieber umfangreich und komfortabel? Gitlab
ist ohnehin viel besser als Github und eben auch self-hosted.

Bleibt noch der Pull-Request. Als dezentrales VCS kann Git selbst sowas
natürlich auch, und zwar ganz klassisch per E-Mail [5]. Bei Gitlab wird
noch an einer Implementierung gearbeitet [4]. Würde es bei Github um
Git gehen, hätten sie das auch implementiert. Aber dann gäbs ja keinen
Lock-In-Effekt für die Nutzer und das ist schlecht fürs Sparschwein.


[1]: https://www.nasdaq.com/symbol/msft/interactive-chart
[2]: https://campussachsen.tu-dresden.de
[3]: https://en.wikipedia.org/wiki/Microsoft_Azure
[4]: https://gitlab.com/gitlab-org/gitlab-ce/issues/4013
[5]: 
https://www.git-scm.com/book/en/v2/Appendix-C%3A-Git-Commands-Email

-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQQ5Hg/KuHjhXHv22JR9EuyVW1QCTgUCXMFUrAAKCRB9EuyVW1QC
TpEaAQCdgRRVMID5Wh5m5qr7BpDiR48BXlT+dVaxHGNuZGnq/gEAscyV+GjdsYIP
xa7hBd+FCuhNyaxLx0smKSwM8+E7aAI=
=Z5Zs
-END PGP SIGNATURE-




Re: Alternative zu github: Weitere sterbende Trends

2019-04-25 Diskussionsfäden Kristian Rink
Hi *;

Am Mittwoch, den 24.04.2019, 18:09 +0200 schrieb Thomas Güttler:
> 
> Microsoft ein üblichen Verdächtiger? Für mich ist MS deutlich auf dem
> Abwertstrend.
> 
> Für's Office interessieren sich auch immer weniger. In der Schule
> (bei meinem Sohn) wird LibreOffice verwendet. Und so braucht es nicht
> mehr lange und die nächste Generation bringt das in die Firmen.
> 

Bei uns bringt die nächste Generation Google Office in die Firmen, wie
ich gelernt habe. Das kommentiere ich lieber nicht nochmal. ;)
Ansonsten habe ich noch eine andere Reflektion, die hier immer mal
wieder die Diskussion prägt: Konkret beim Thema Cloud (Azure) ist die
Frage zu stellen, ob Microsoft wirklich noch "der Böse" ist, wenn man
das mit den anderen Offerten (Amazon, Google) vergleicht. 

> > Ich empfand es als einigermaßen ironisch, dass du für deinen
> > Nachruf an all die altehrwürdigen Technologien der IT-Branche
> > ausgerechnet auf einen der wichtigsten Negativtrends aufspringst.
> 
> Für mich ist es der bequemste Weg.
> 
> Welche Alternative zu github siehst du für die wenigen Bytes hier?
> 
>https://github.com/guettli/deadends-of-it
> 

Aus reiner Neugier: Du hast eine eigene Domain mit eigenem Webhosting,
wie ich gesehen habe. Warum den Artikel nicht dort ablegen, sondern bei
github? ;)

Viele Grüße,
Kristian




Self-Hosting vs. Cloud (was: Re: tine20. War: der Job des E-Mail-Administrators hat keine Zukunft)

2019-04-25 Diskussionsfäden Kristian Rink
Am Mittwoch, den 24.04.2019, 18:02 +0200 schrieb Thomas Güttler:
> 
> Wenn ich eine Termineinladung per Mail bekomme, kann ich die im
> Thunderbird akzeptieren.
> Dumm ist bloß, dass diese Info ("Thomas G wird teilnehmen") nicht zum
> Einladenden kommt.
> 

Ja, wir sind eine ähnliche Route gegangen. Über die Jahre haben und
hatten wir immer einen starken DIY/Selfhosting-Background, haben viel
unserer notwendigen Infrastruktur inhouse betrieben, den überwiegenden
Teil davon auf Linux/Debian. Das hat auch über Jahre hinweg gut
geklappt. Über lange Zeit waren die Mitarbeiter auch "privat" relativ
untechnisiert, haben bestenfalls SMS auf Mobiltelefonen geschrieben und
hatten Technik im Büro.

Spätestens mit den Smartphones, Google, Apple beobachte ich hier
grundlegende Änderungen, die vor allem auch in die Erwartungshaltung an
die Firmen-IT hinein strahlen. Die Nutzer sehen, was möglich ist.
Mithin:

Plötzlich *wollen* die Leute nicht mehr akzeptieren, daß es (in der
Konstruktion mit lokalem SMTP/IMAP-Server und verschiedenen
CalDAV/Groupware-Systemen, die wir in den Jahren probiert haben) über
einen Desktop-Kalender schwierig bis unmöglich ist, (a) die
Terminkalender aller relevanten internen Beteiligten und des
Besprechungsraumes für eine Terminfindung zu sehen, (b) einen Termin
festzulegen, in der einer der Besprechungsräume und alle Beteiligten
verfügbar sind, (c) der dann auch diese Ressourcen, und sei es
vorläufig, "blockt" und (d) nach Empfang/Bestätigung durch die
Beteiligten "verbindlich wird. 

Plötzlich *wollen* die Leute auch nicht mehr akzeptieren, daß Instant
Messaging über das lokale XMPP-System auf den Arbeitsplätzen mit
Clients passiert, die wie 1990er-ICQ aussehen und sich auch genau so
bedienen lassen, bei denen der Verlauf bestenfalls "zufällig" zwischen
den Geräten synchronisiert und man unter Umständen auch mal Nachrichten
übersieht, weil der Client entweder beim Minimieren den Konferenzraum
verloren hat oder es nicht für nötig erachtete, eine Benachrichtigung
zu zeigen.

Plötzlich *wollen* die Leute nicht mehr hinnehmen, daß Argumente wie
"Datenschutz", "wir können es selbst betreiben" und "es ist Open-
Source" ins Feld geführt werden als Begründung dafür, daß nur 75% der
Features abgedeckt werden, die andere "marktgängige" Lösungen können,
und vor allem die tatsächlich relevanten Use Cases schlecht bis nicht
funktionieren. Warum auch? Am Ende des Tages legt Dir Google GDPR-
Compliance vor, gibt Dir einen korrekten AV-Vertrag, der ISMS-Mensch
nickt das ab, damit ist doch alles gut...?

Was ist bei uns dann zunächst passiert? Shadow IT. Der interne Chat
wurde den Erwartungshaltungen nicht mehr gerecht, also haben sich die
Leute eine WhatsApp-Gruppe aufgemacht, die Entwickler einen Slack-
Channel (weil sie das auch von Open-Source-Projekten schon kannten) Der
interne Kalender blieb hinter den funktionalen Wünschen zurück, also
haben die Kollegen begonnen, sich selbst mit Google Calendar auf ihren
Androids und im Browser zu helfen, um dienstliche Termine zu
koordinieren. Daneben (ich habe leider nicht die komfortable Situation,
*nicht* für den Betrieb der Infrastruktur verantwortlich zu sein)
merkst Du, wenn Dir eine beliebige Groupware-Komponente (wir haben mit
ownCloud-Erweiterungen wie auch Open-XChange versucht zu arbeiten) bei
einem weiteren Upgrade auf die Füße fällt, daß das Aufrechterhalten
dieser Infrastruktur immer mehr Zeit und Energie kostet, die Dir an
anderen, wichtigeren Stellen (Entwicklung, Betrieb, Optimierung unserer
eigenen Anwendungen und Dienste) einfach fehlt. Erschwerend kommt
hinzu, daß es derzeit nahezu aussichtslos ist, Personal für den
systematischen Betrieb komplexerer Infrastruktur auf Linux-Basis am
Markt zu finden. 

Irgendwann bleibt die Frage, wie "low-level" Du benötigte Dienste
selbst betreiben kannst und willst. Ich bin nicht restlos glücklich
über diese Entwicklung, sehe aber im Umkehrschluß auch, daß wir auch in
anderen Bereichen "Spezialisierung" erleben und das Level, unterhalb
dessen man Dienstleistungen einkauft, stückweise "nach oben" rutscht.
Vor Unix war Computing noch sehr massiv an tatsächliche Hardware
gebunden. Mit Unix und später Windows ist die Abstraktion eine Ebene
weiter hoch gerutscht, hat man angefangen, Anwendungen für ein
Betriebssystem, nicht mehr für eine spezielle Maschine zu schreiben.
Mit Virtualisierung haben wir es intern irgendwann geschafft,
Anwendungen auf VM-Basis zu bündeln und auszurollen und haben keine
Zeit mehr damit verschwendet, mit dem IBM-Support darüber zu
diskutieren, daß wir auf dem supporteten e-Series-Servern Debian und
nicht RedHat oder SuSE fahren wollen. 

Mittlerweile haben wir Technologien wie docker und lassen die
Entwickler (mit deutlich geringerem administrativen Aufwand und weniger
Reibereien) Anwendungen in Containern packen, die teilweise bei uns,
teilweise in Container-Infrastruktur im RZ unseres Dresdner Providers
laufen. Mit Amazon Lambda, "Function-as-a-service" und dem ganzen Kram
wird sich