https://mediawiki.a-eskwadraat.nl/wiki/api.php?action=feedcontributions&feedformat=atom&user=JohandA-Eskwiki - User contributions [en]2026-08-10T11:20:54ZUser contributionsMediaWiki 1.23.2https://mediawiki.a-eskwadraat.nl/wiki/index.php/WebdavWebdav2015-12-30T19:40:45Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:WebDav}}<br />
<br />
[https://en.wikipedia.org/wiki/WebDAV WebDav] is een protocol bovenop HTTP waarmee je bestanden kunt ophalen en aanpassen op afstand en is daarmee in functionaliteit vergelijkbaar met bijvoorbeeld [https://en.wikipedia.org/wiki/File_Transfer_Protocol FTP]. Het voordeel van [https://en.wikipedia.org/wiki/WebDAV WebDav] over [https://en.wikipedia.org/wiki/File_Transfer_Protocol FTP] is, is dat [https://en.wikipedia.org/wiki/WebDAV WebDav] makkelijk SSL ondersteunt. Er is geen standaard variant van FTP over SSL die goed is ondersteund. WebDav + ssl wordt in de windows explorer gewoon standaard ondersteund, terwijl dit voor beveiligde FTP niet het geval is. Dit maakt het makkelijk om bij bestanden van A-Eskwadraat te komen, terwijl het nog wel veilig is.<br />
<br />
== Implementatie ==<br />
<br />
Standaard WebDav implementaties zoals mod_webdav van apache zijn niet flexibel te integreren met home directories, in tegenstelling tot FTP. Daarom draaien we een gepatchte versie van SabreDav die runtime de UID van het php proces aanpast, zodat deze hetzelfde is als de user die inlogt. Het inloggen wordt gedaan via mod_authnz_pam, en is daardoor een beetje traag, ook al wordt lokaal een hoop aan credential caching gedaan en hangt de vm-webdav niet aan ipa, maar direct met ldap en caching via ns(l)cd. Een constructie die niet wordt aangeraden, maar wel acceptabel werkt. De relevante code is terug te vinden is Salt. Het meest relevante is de custom authenticatie backend waar de setuid e.d. gebeurd.<br />
Het kan zijn dat na een update van SabreDAV bestanden aangepast, geherpatched moeten worden.<br />
<br />
== Handleiding ==<br />
Een handleiding voor het gebruik van WebDav is [https://home.a-eskwadraat.nl/~sysop/handleidingen/webdav.pdf hier] te vinden.<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/WebdavWebdav2015-12-30T18:09:03Z<p>Johand: Created page with "[https://en.wikipedia.org/wiki/WebDAV WebDav] is een protocol bovenop HTTP waarmee je bestanden kunt ophalen en aanpassen op afstand en is daarmee in functionaliteit vergelijk..."</p>
<hr />
<div>[https://en.wikipedia.org/wiki/WebDAV WebDav] is een protocol bovenop HTTP waarmee je bestanden kunt ophalen en aanpassen op afstand en is daarmee in functionaliteit vergelijkbaar met bijvoorbeeld [https://en.wikipedia.org/wiki/File_Transfer_Protocol FTP]. Het voordeel van [https://en.wikipedia.org/wiki/WebDAV WebDav]<br />
<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/MailMail2015-12-30T17:26:21Z<p>Johand: </p>
<hr />
<div>Bij A–Eskwadraat gebruiken we '''Maildir''' voor de opslag van e-mail. Hiervoor gebruikten we het mbox-formaat. We raden gebruikers aan om niet direct de Maildirmappen te benaderen, maar om dit via [http://en.wikipedia.org/wiki/Internet_Message_Access_Protocol IMAP] te doen. De standaardconfiguratie van de meeste mailclients staat hier ook voor ingesteld.<br />
<br />
== Services ==<br />
<br />
Op [[Haskell|haskell]] draait de virtuele machine [[Vm-mail|vm-mail]] om het mailverkeer van en naar A-Eskwadraat te regelen:<br />
<br />
*[http://www.exim.org/ exim] (''/etc/exim4/'') verwerkt in principe alle binnenkomende mails, en wat er waarheen doorgestuurd moet worden;<br />
*[http://www.dovecot.org/ dovecot] (''/etc/dovecot/'') neemt de POP- en IMAP-servers voor zijn rekening;<br />
*[http://spamassassin.apache.org/ SpamAssassin] (''/etc/mail/spamassassin/'') [[Mailfiltering|filtert]] het binnenkomende mailverkeer;<br />
*[http://http://www.clamav.net/lang/en/ ClamAV] (''/etc/clamd.d/'') scant het mailverkeer voor virussen en dergelijke;<br />
*[http://squirrelmail.org SquirrelMail] (''/etc/squirrelmail/'') is een webmail interface SquirrelMail draait in de webserver van [[Vm-mail|vm-mail]];<br />
*[http://www.list.org/ Mailman] (''/etc/mailman/'') Mailman is verantwoordelijk voor de mailing lists, zoals de BBCie-announce.<br />
<br />
== Naamgeving Maildirmappen ==<br />
<br />
Let op dat om voor dovecot begrijpbare namen te hebben, de mappen op in ''~/Maildir'' altijd met een punt moeten beginnen. Submappen werken ook op deze manier. Een paar voorbeelden:<br />
<br />
*''~/Maildir/.Intro/'' voor de IMAP-map ''Intro'';<br />
*''~/Maildir/.Sysop.postmaster/'' voor de map ''postmaster'' als submap van ''Sysop''.<br />
<br />
Als de mappen via IMAP worden aangemaakt gebeurt dit automatisch.<br />
<br />
== Postfix ==<br />
<br />
Postfix is de SMTP server voor de nieuwe mail server.<br />
<br />
Postfix gebruikt meerdere ports om mail te ontvangen en te verwerken. Inkomende mail van leden moet naar de SMTP daemon op port 587 worden gestuurd. Authenticatie en TLS encryptie zijn een vereiste op deze verbinding. In de toekomst zal de [[Router|Router]] de encryptie tussen client en mail-server regelen. Alle andere mail komt binnen op port 25. Spam- en virus-filtering gebeurd via de SMTP daemons op ports 10025 en 10027 voor onbekende en bekende mail, respectievelijk. Lees ''/etc/postfix/master.cf'' voor de configuratie van deze SMTP daemons.<br />
<br />
=== Transport ===<br />
<br />
Eerst checkt Postfix of de inkomende mail aan een lokaal mailadres is gestuurd. Vervolgens word het adres verandert aan de hand van de alias mappen in /etc/postfix/aliases. De mail word naar elke resulterende gebruiker gestuurd via de instellingen van hun ''.forward'' bestand. Welke domeinen als 'lokaal' worden bestempeld staat in ''/etc/postfix/domains/local''.<br />
<br />
Daarna checkt Postfix of de inkomende mail naar een virtueel domein is gestuurd. Domeinen zoals turingslegacy.nl worden via een aliasmap herschreven, en de herschreven mail word van begins af aan verwerkt door Postfix. De virtuele domeinen staan in ''/etc/postfix/domains/virtual''.<br />
<br />
Als laatste checkt Postfix of de inkomende mail is gestuurd naar een domein waarvoor A-Eskwadraat mail relayed. Deze mail word onveranderd naar de mail-server van dit domein verstuurd (relaying). Dit voorkomt verlies van mail voor het externe domein wanneer hun mailserver uitvalt, aangezien A-Eskwadraat de secondary mailserver is voor dat domein.<br />
<br />
Een uitzondering op de regel is mail bedoeld voor de webserver. Mail aan de webcie komt binnen op de mail server, maar moet worden doorgestuurd naar de webserver. De verwijzingen zijn te vinden in ''/etc/postfix/transport_www'' en ''/etc/postfix/transport_regex''.<br />
<br />
Let op dat deze uitleg heel erg bot is. Lees de relevante ''man'' pages van Postfix om te leren hoe mail word verwerkt. Let op dat veranderingen in een alias/transport/domain map niet worden opgemerkt tot het ''postmap'' of ''postalias'' op het bestand is aangeroepen!<br />
<br />
=== Mailfiltering ===<br />
<br />
Postfix maakt gebruik van amavisd voor het filteren van de inkomende mail. Amavis is een interface voor SpamAssassin welke spam filtert en ClamAV welke mails op virussen scant. Check de configuratie op [[Vm-saltmaster|vm-saltmaster]] voor details.<br />
<br />
Om de virus database up te daten:<br />
<pre>freshclam<br />
</pre><br />
<br />
== Mailman ==<br />
<br />
Mailman is verantwoordelijk voor de infrastructuur van de mailing lists. De mailing lists zijn te vinden op [lists.a-eskwadraat.nl/mailman lists.a-eskwadraat.nl/mailman]. Er zijn twee belangrijke services om mailman te draaien: mailman en httpd. De configuratie van mailman bevind zich in ''/etc/mailman/'', de data bevind zich in ''/var/lib/mailman'', en de binaries bevinden zich in ''/usr/lib/mailman''.<br />
<br />
Gebruik de scripts in /usr/lib/mailman/bin om de mailing lists vanaf de command-line te wijzigen. De volgende commando's zijn belangrijk bij het debuggen / migreren van mailman:<br />
<br />
*check_perms: repareert de bestandsrechten van mailman-specifieke bestanden.<br />
*with_list & fix_url: repareert de links van de mailman archieven indien deze zijn veranderd.<br />
<br />
Lees de [http://wiki.list.org/DOC/4.09%20Summary%20of%20the%20mailman%20bin%20commands MailmanWiki] voor een samenvatting van alle commands.<br />
<br />
Mailman werkt samen met de Postfix mailserver via de alias map ''/etc/mailman/aliases''. Voer het volgende commando uit na het toevoegen/verwijderen van een lijst zodat Postfix zijn alias database update:<br />
<pre>postalias /etc/mailman/aliases<br />
</pre><br />
<br />
Na een migratie van de mailman lijsten is het belangrijk om ''restorecon'' uit te voeren op ''/var/lib/mailman''. Mailman en SELinux werken prima samen zolang de rechten maar goed staan.<br />
<pre># Samenvatting van een Mailman migratie.<br />
# Op de nieuwe mailserver.<br />
rsync -azv -e "ssh -i <sshkey>" <OUDEHOST>:/var/lib/mailman/ /var/lib/mailman/<br />
restorecon -r /var/lib/mailman/<br />
cd /usr/lib/mailman/<br />
bin/check_perms -f<br />
bin/withlist -l -a -r fix_url<br />
</pre><br />
<br />
== Dovecot ==<br />
<br />
Dovecot is de IMAP server verantwoordelijk voor het ophalen en beheren van de mail opgeslagen in de homedirs. Mail wordt opgeslagen in de .Maildir van een gebruik zijn home directory. Momenteel is vm-mail de actieve IMAP server van A-Eskwadraat. De server luistert op poort 143 (standaard IMAP poort) en vereist een TLS-encrypted verbinding van de gebruiker. Het certificaat voor de verbinding is anders dan het certificaat van de webserver.&nbsp; Dovecot authenticeert gebruikers door middel van SASL-kerberos met de IPA servers. Dovecot werkt ook als authenticatie-server voor postfix door middel van een open socket. Een SELinux module is vereist om Postfix toegang te geven tot de socket.<br />
<br />
Voor meer configuratie details, zie de configuratie op de salt-master. (CentOS 6: /srv/salt/centos/vm-mail/dovecot, CentOS 7: /srv/salt/centos7/dovecot)<br />
<br />
'''AL DE CONFIGURATIE HIERONDER IS GIGANTISCH OUT OF DATE''' \/\/\/<br />
<br />
== Configuratie mailfilters ==<br />
<br />
Gebruik je een ''.forward'' of ''.procmailrc'' om e-mail direct in mappen te stoppen, let dan op de naamgeving (zie hierboven) en zorg ervoor dat de mappen altijd op een ''/'' eindigen. Begin je ''.procmailrc'' ook altijd met de regel<br />
<br />
MAILDIR=$HOME/Maildir/<br />
<br />
om te zorgen dat e-mail toch niet in ''/var/mail'' terechtkomt.<br />
<br />
== Maak een mailserver met exim, en dovecot ==<br />
<br />
Zorg eerst dat sendmail uit staat!<br />
<pre>service sendmail stop<br />
chkconfig sendmail off<br />
</pre><br />
<br />
Bij voorkeur verwijder je ook de package voor [[Postfix|postfix]]. Deze is standaard bij CentOS geïnstalleerd.<br />
<br />
=== Exim ===<br />
<br />
Exim is een MTA (Mail Transfer Agent) en is ervoor om mailtjes te versturen, ontvangen, en doorsturen. Dit gebeurd uiteraard op de mailserver!<br />
<br />
Installeer allereerst exim op de host.<br />
<pre># yum install exim<br />
</pre><br />
<br />
Verander vervolgens het configuratie bestand /etc/exim/exim.conf:<br />
<pre># Het Mail domain - normaal gesproken a-eskwadraat.nl<br />
primary_hostname = circle.a-eskwadraat.nl<br />
<br />
# Weiger met ipv6 te werken.<br />
local_interfaces = 0.0.0.0<br />
disable_ipv6 = true<br />
<br />
daemon_smtp_ports = smtp&nbsp;: submission<br />
accept_8bitmime = true<br />
<br />
<br />
# Lijsten van geldige mail domainin.<br />
domainlist mailman_domains = CONFDIR/domains.mailman<br />
domainlist local_domains = @&nbsp;: CONFDIR/domains.local&nbsp;: +mailman_domains&nbsp;: lsearch;CONFDIR/domains.virtual<br />
domainlist relay_to_domains = CONFDIR/domains.relay<br />
<br />
hostlist relay_from_hosts = 10.14.3.0/22<br />
<br />
# Backup mail server in het geval dat onze niet werkt.<br />
hostlist mx_hosts = mail.wolffelaar.nl<br />
<br />
qualify_domain = A-Eskwadraat.nl<br />
<br />
queue_run_max = 250<br />
<br />
smtp_accept_max = 100<br />
smtp_accept_max_per_host = ${if match_ip{$sender_host_address}{+mx_hosts}{50}{10}}<br />
<br />
received_headers_max = 30<br />
<br />
RETRY_SECONDARY=F,90d,15m<br />
RETRY_REST=F,2h,15m; G,16h,2h,1.5; F,4d,8h<br />
<br />
acl_smtp_rcpt = acl_check_rcpt<br />
acl_not_smtp_start = acl_check_not_smtp<br />
acl_smtp_data = acl_check_data<br />
<br />
host_lookup = *<br />
helo_try_verify_hosts =&nbsp;!@&nbsp;:&nbsp;!@[]<br />
helo_allow_chars = _<br />
<br />
# ClamAV - The Anti-Virus Scanner<br />
av_scanner = clamd:/var/run/clamav/clamd.sock<br />
<br />
# Custom 5s limiet.<br />
rfc1413_query_timeout = 5s<br />
<br />
# Mailman support, als per /usr/share/doc/mailman/README.EXIM.gz<br />
MAILMAN_HOME=/var/lib/mailman<br />
MAILMAN_WRAP=/usr/lib/mailman/mail/mailman<br />
MAILMAN_USER=mailman<br />
MAILMAN_GROUP=mailman<br />
</pre><br />
<br />
=== Dovecot ===<br />
<br />
Dovecot is een IMAP en POP3 server, wat inhoud dat het mailtjes kan ontvangen, iets wat best wel handig is om te hebben. Installeer dovecot op je mailserver als je dat nog niet gedaan hebt. Verander dan nu het volgende:<br />
<br />
In /etc/dovecot/dovecot.conf:<br />
<br />
*protocols = imap<br />
*login_trusted_networks = &lt;ip-adressen die je vertrouwd&gt;<br />
<br />
In /etc/dovecot/conf.d/10-mail.conf<br />
<br />
*mail_location = maildir:~/Maildir<br />
*lock_method = dotlock<br />
<br />
In /etc/dovecot/conf.d/10-auth.conf<br />
<br />
*disable_plaintext_auth = no<br />
*auth_realms = aeskwadraat<br />
*auth_default_realm = aeskwadraat<br />
*auth_gssapi_hostname = &lt;ipa-server&gt;<br />
*auth_krb5_keytab = /etc/dovecot/krb5.keytab<br />
*auth_mechanisms = plain gssapi<br />
<br />
en zet op het einde<br />
<pre>userdb {<br />
driver = static<br />
args = uid=dovecot gid=dovecot home=/var/spool/mail/%u<br />
}<br />
</pre><br />
<br />
Maak nu op de ipa-server een service imap aan met de mailserver als host. Dit kan je doen via de webinterface. Voer vervolgens het volgende uit op de mailserver:<br />
<pre>kinit admin<br />
ipa-getkeytab -s <ipa-server> -p imap/<mailserver> -k /etc/dovecot/krb5.keytab<br />
chown root:dovecot /etc/dovecot/krb5.keytab<br />
chmod 640 /etc/dovecot/krb5.keytab<br />
</pre><br />
<br />
Restart dovecot en zet hem standaard aan:<br />
<pre>service dovecot restart<br />
chkconfig dovecot on<br />
</pre><br />
<br />
Zet tenslotte nog met system-config-firewall-tui 'imap over ssl' en 'mail (smtp)' aan, en voila! Je kan nu met ipa-users gebruik maken van IMAP om mailtjes te ontvangen!<br />
<br />
Je kan eventueel in /etc/postfix/main.cf en /etc/dovecot/conf.d/10-mail.conf nog het een ander van waar de mail wordt opgeslagen veranderen.<br />
<br />
=== Spamassassin ===<br />
<br />
Spamassassin is een mailfilteringprogramma voor spam. Om het te installeren:<br />
<pre>yum install spamassassin<br />
</pre><br />
<br />
Maak nu de user en group spamd aan:<br />
<pre>groupadd -g 5001 spamd<br />
useradd -u 5001 -g spamd -s /sbin/nologin -d /var/lib/spamassassin spamd<br />
mkdir /var/lib/spamassassin<br />
chown spamd:spamd /var/lib/spamassassin<br />
</pre><br />
<br />
Zet dan het volgende in /etc/mail/spamassassin/local.cf:<br />
<pre>required_score 5.0<br />
report_safe 0<br />
rewrite_header Subject [***SPAM***]<br />
<br />
# Enable the Bayes system<br />
use_bayes 1<br />
use_bayes_rules 1<br />
# Enable Bayes auto-learning<br />
bayes_auto_learn 1<br />
</pre><br />
<br />
Verander nu in /etc/postfix/master.cf<br />
<pre>smtp inet n - n - - smtpd<br />
</pre><br />
<br />
in<br />
<pre>smtp inet n - n - - smtpd -o content_filter=spamassassin<br />
</pre><br />
<br />
en stop op het einde van master.cf:<br />
<pre>spamassassin unix - n n - - pipe flags=R user=spamd argv=/usr/bin/spamc -e /usr/sbin/sendmail -oi -f ${sender} ${recipient}<br />
</pre><br />
<br />
Restart nu spamassassin en postfix:<br />
<pre>chkconfig spamassassin on<br />
service spamassassin restart<br />
service postfix restart<br />
</pre><br />
<br />
=== Aliases ===<br />
<br />
In postfix staan de locaties van de aliases in /etc/postfix/main.cf. Deze kan je vinden bij de regel 'alias_maps = ...'. Als je een nieuw aliasbestand wilt toevoegen, voeg dit dan ook toe bij deze regel als hash:&lt;bestandslocatie&gt;. Vergeet ook niet om dit toe te voegen bij alias_database!.<br />
<br />
De aliases zelf staan geconfigureerd in de aliasbestanden die te vinden zijn onder /etc/aesalias/. Nadat je een nieuw alias hebt toegevoegd moet je het commando 'newaliases' als root uitvoeren om de nieuwe alias(sen) te activeren. Hetzelfde moet je ook doen als je aliases weghaalt natuurlijk!<br />
<br />
== Instellingen ==<br />
<br />
=== Postfix ===<br />
<br />
==== Mail relay ====<br />
<br />
Postfix kan mail relayen naar een extern domein. Hiervoor is de volgende regel:<br />
<pre>relay_domains = $mydestination, hash:/etc/postfix/domains.relay<br />
</pre><br />
<br />
In het bestand /etc/postfix/domains.relay staat de lijst van alle externe domains waar mail naar toe gerelayed wordt. Als je iets in het bestand wijzigt, vergeet dan niet om daarna het commando<br />
<pre>postmap /etc/postfix/domains.relay<br />
</pre><br />
<br />
uit te voeren.<br />
<br />
==== Whitelist ====<br />
<br />
Postfix kan gebruik maken van een whitelist. Zorg hiervoor dat er het volgende in /etc/postfix/main.cf staat:<br />
<pre>smtpd_client_restrictions = check_client_access hash:/etc/postfix/client.access<br />
</pre><br />
<br />
In het bestand /etc/postfix/client.access staat de lijst van alle domains die geweigerd en toegelaten worden. Als je hier iets in verandert, vergeet dan niet om uit te voeren<br />
<pre>postmap /etc/postfix/access.client<br />
</pre><br />
<br />
== SquirrelMail ==<br />
<br />
SquirrelMail is een webmail-client.<br />
<br />
=== SquirrelMail installeren ===<br />
<br />
Installeer eerst natuurlijk Squirrelmail:<br />
<pre>yum install squirrelmail<br />
</pre><br />
<br />
Zorg ervoor dat httpd standaard aan staat en start httpd:<br />
<pre>chkconfig httpd on<br />
service httpd start<br />
</pre><br />
<br />
Verander nu het volgende in /etc/squirrelmail/config.php:<br />
<pre>$org_name = "A-Eskwadraat";<br />
$org_logo = SM_PATH . 'images/sm_logo.png';<br />
$org_logo_width = '308';<br />
$org_logo_height = '111';<br />
$org_title = 'A-Eskwadraat SquirrelMail $version";<br />
$signout_page = 'vm-mail.a-eskwadraat.nl';<br />
<br />
$domain = 'circle.a-eskwadraat.nl';<br />
$imapServerAddress = 'localhost';<br />
$useSendmail = false;<br />
$smtpServerAddress = 'localhost';<br />
$pop_before_smtp = false;<br />
<br />
</pre><br />
<br />
Zet nu het A-Eskwadraat logo in de squirrelmail config map.<br />
<pre>setsebool -P httpd_can_network_connect 1<br />
</pre><br />
<br />
== RoundcubeMail ==<br />
<br />
Roundcube is ook een webmail client.<br />
<br />
=== Installeren ===<br />
<br />
Op vm-salt-master staat een configuratie voor een Roundcube mail VM met een korte readme. Deze zorgt ervoor dat httpd, roundcubemail en mariadb geinstalleerd staan. Salt een VM met deze configuratie.<br />
<pre>salt '$hostname' state.highstate<br />
</pre><br />
<br />
Laat vervolgens httpd van die VM door de firewall heen. Daarna moet de database voor Roundcube geinitialiseerd worden. Dit gaat met mysql.<br />
<pre>CREATE DATABASE roundcubemail;<br />
GRANT ALL PRIVILEGES on roundcubemail.* TO roundcube@localhost IDENTIFIED BY '$password';<br />
FLUSH PRIVILEGES;<br />
</pre><br />
<br />
Nu moet de timezone nog even ingesteld worden in /etc/php.ini op de roundcube VM. Daarna moeten er nog de juiste tables in de database worden gezet. Dit kan door op de nieuwe VM de bestanden in /etc/roundcubemail/databasefiles te runnen met mysql.<br />
<pre>mysql roundcubemail < mysql.initial.sql<br />
</pre><br />
<br />
== Mail Authorizatie ==<br />
<br />
Om te controleren of een gebruiker wel als een adres mag mailen wordt gebruik gemaakt van een sender_login_maps, die in een database de users opzoekt die als gegeven adres mogen versturen. Dit is een python script die op de vm-sysop staat bij de sysop api, aangezien daar de mail aliases al staan voor de alias_check. Het python script, te vinden in `/var/www/html/api/python/mail-authorization.py`, loopt recursief langs alle users die in cies, bestuur, extern of iba zitten en kijkt daarnaast ook naar mail aliassen. Aan de hand hiervan wordt met een sql query alle transitieve relaties expliciet gemaakt, zodat dit niet runtime gedaan moet worden. Als een alias naar een cie wordt doorgestuurd, en een user weer in die cie zit, wil je dat die user ook als die alias mag mailen. Als database wordt PostgreSQL gebruikt op de vm-database. De database die gebruikt wordt heet "mail". In de python code staan nog wat comments. Er draait op de vm-sysop een cron die af en toe de database refreshed. Daarnaast is het python script ook intern bereikbaar [http://vm-sysop.a-eskwadraat.nl/api/python/mail-authorization.py hier]. Bij het laden van deze pagina wordt de database gerefreshed. Op deze manier kan de database meteen gerefreshed worden zodra iemand toegevoegd is aan een cie. Als er in een alias een wildcard staat (*@bapc.eu: bapc), wat betekend dat alles van het domein bapc.eu naar de bapc commissie wordt gestuurd, wordt dit omgezet naar een SQL wildcard, wat uiteindelijk dus netjes werkt.<br />
<br />
Als er via SMTP een request gedaan wordt om van buitenaf een mail te versturen doet postfix een query en kijkt welke users als die alias mail mogen versturen. Deze config is op de vm-mailpp te vinden in `/etc/postfix/alias_auth.cf`.<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/ZFSZFS2015-12-30T16:53:26Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:ZFS}}<br />
<br />
[http://en.wikipedia.org/wiki/ZFS ZFS] is het file system dat gebruikt wordt om alle actieve data in op te slaan op [[Haskell|Haskell]]. Oorspronkelijk is het ontwikkeld door Sun Microsystems voor [http://en.wikipedia.org/wiki/Solaris_(operating_system) Solaris]. Vervolgens is het geport naar onder andere [https://wiki.freebsd.org/ZFS FreeBSD] en [http://zfsonlinux.org/ Linux]. Omdat het ontwikkeld is onder de [http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License CDDL] license en daarom is [http://zfsonlinux.org/ ZFS on Linux] geen onderdeel van de kernel, maar een losse module die via dkms apart ingeladen moet worden. Op [[Haskell|Haskell]] draait ZFS dus ook niet voor zijn root partitie, maar alleen voor data partities. Het zou anders kunnen dat bij een kernel of zfs update de kernel modules niet goed gebouwd worden je uberhaupt niet kan booten en dit is vrij problematisch.<br />
<br />
== Volume Manager vs File System ==<br />
<br />
ZFS is niet alleen een file system, het is ook een volume manager, zoals [http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux) LVM]. Het is belangrijk om dit verschil tussen deze 2 lagen in het achterhoofd te houden. De bovenste laag heet bij ZFS de pool. De pool bestaat uit een aantal disks. Deze kunnen dan gemirrored worden, of in een willekeurige raid gezet worden. Deze pool werkt ongeveer hetzelfde als bij LVM. Er is een pool met data beschikbaar en deze kan vervolgens weer gesplitst worden in datasets. Elke dataset heeft een aantal properties. Veel opties die bij andere dingen als mount opties in de fstab staan zijn in ZFS properties (mountpoint/extended attributes/atime/compressie). Er is ook een ZFS service en die regelt bij het opstarten alles zelf met betrekking tot mounten en sharen van file systems, dus er is niets van zfs te zien in /etc/fstab.<br />
<br />
== Raid Configuratie ==<br />
<br />
ZFS draait in een zogehete raidz2. Dit is in feite een raid 6 met wat extra voordelen, vanwege de integratie. Raidz's hebben geen last van het zogeheten [http://www.raid-recovery-guide.com/raid5-write-hole.aspx Write Hole] probleem. Bij een raidz2/raid6 kunnen er 2 disks uitvallen voordat dataverlies optreed.<br />
<br />
== Versies ==<br />
<br />
ZFSonLinux is een aparte kernel module en er komen geregeld nieuwe versies uit. De updates zijn tamelijk grondig, dus het is verstandig niet direct te upgraden zodra er een nieuwe release uit is. Op moment van schrijven draait Haskell ZoL 0.6.3-1 en Max draait 0.6.3. Nieuwe versies zijn altijd backwards compatible. Ze bieden echter wel de optie aan om de pool te upgraden naar de nieuwe versies, zodat er gebruik gemaakt kan worden van nieuwe functionaliteit. Wees dus terughoudend met het upgraden van de pool. Het is ook handig om de github, te vinden op [https://github.com/zfsonlinux/zfs/issues https://github.com/zfsonlinux/zfs/issues], in de gaten te houden om te kijken of er niet al te veel problemen zijn met de nieuwe versies.<br />
<br />
Na het updaten van ZFS of de kernel kan het nog wel eens gebeuren dat de package manager de nieuwe modules niet goed build en dat dit handmatig gebeuren moet. Dit gebeurd met de volgende commandos. Na het builden moet de zpool nog handmatig geimporteerd worden, dus schrik niet als je geen pools ziet.<br />
<br />
dkms install spl/<VERSION><br />
dkms install zfs/<VERSION><br />
<br />
Waar &lt;VERSION&gt; de versie van zfs is, dus bv 0.6.5.<br />
<br />
== Blocksize problemen ==<br />
<br />
Het aanmaken van de raidz6 pool is gebeurd met 4 sas schijven + 2 dummy's. De dummy's zijn later vervangen door 2 seagate's. De sas schijven hebben echter een blocksize van 512 en de pool heeft daardoor ook een blocksize van 512 gekregen. De seagates hebben echter een blocksize van 4096, waardoor write amplification optreed. Andersom zou dit geen probleem zijn. De write performance van de pool is hierdoor drastisch lager, potentieel 8x. Of de pool moet opnieuw gemaakt worden, of de seagate's moeten worden vervangen door schijven met een physical block size van 512 byte.<br />
<br />
== Caching ==<br />
<br />
ZFS heeft eigen caching mechanismes die buiten de linux page cache om gaat. Er zijn 2 belangrijke caches die belangrijk zijn. De ram caching. Deze heet de ARC en is ingesteld op 4GB. Daarnaast wordt er aan write caching gedaan. Data wordt eerst naar SSD geschreven en dan pas naar HDD. Deze write cache heet de ZIL (ZFS Intent Log). Statistieken over o.a. deze caches kunnen gevonden worden in `/proc/spl/kstat/zfs`<br />
<br />
<br />
<br />
== Do's and Don't ==<br />
<br />
=== Do's ===<br />
<br />
*De man pages van de commando's zfs en zpool zijn zeer uitgebreid. In het geval dat je niet helemaal weet hoe iets werkt, kijk eerst in de man page.<br />
*Er is een stuk over ZFS in de sysop inwerking, te vinden op [https://home.a-eskwadraat.nl/~sysop/inwerking/inwerking.pdf https://home.a-eskwadraat.nl/~sysop/inwerking/inwerking.pdf], dit is een goede start om een beetje bekend te raken met ZFS.<br />
<br />
man zpool<br />
man zfs<br />
<br />
=== Dont's ===<br />
<br />
*Wees voorzichting met zfs destroy, dubbelcheck altijd als je iets wilt verwijderen.<br />
*Als je met disks bezig bent, werkt altijd met /dev/disk/by-id/.. en niet met kale /dev/sda e.d.<br />
*Doe nooit iets met zpool labelclear, dit doet enge dingen met je partities.<br />
*Wees voorzichtig met het upgraden van ZFS.<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/ZFSZFS2015-12-30T16:52:43Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:ZFS}} [http://en.wikipedia.org/wiki/ZFS ZFS] is het file system dat gebruikt wordt om alle actieve data in op te slaan op [[Haskell|Haskell]]. Oorspronkelijk is het ontwikkeld door Sun Microsystems voor [http://en.wikipedia.org/wiki/Solaris_(operating_system) Solaris]. Vervolgens is het geport naar onder andere [https://wiki.freebsd.org/ZFS FreeBSD] en [http://zfsonlinux.org/ Linux]. Omdat het ontwikkeld is onder de [http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License CDDL] license en daarom is [http://zfsonlinux.org/ ZFS on Linux] geen onderdeel van de kernel, maar een losse module die via dkms apart ingeladen moet worden. Op [[Haskell|Haskell]] draait ZFS dus ook niet voor zijn root partitie, maar alleen voor data partities. Het zou anders kunnen dat bij een kernel of zfs update de kernel modules niet goed gebouwd worden je uberhaupt niet kan booten en dit is vrij problematisch.<br />
<br />
== Volume Manager vs File System ==<br />
<br />
ZFS is niet alleen een file system, het is ook een volume manager, zoals [http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux) LVM]. Het is belangrijk om dit verschil tussen deze 2 lagen in het achterhoofd te houden. De bovenste laag heet bij ZFS de pool. De pool bestaat uit een aantal disks. Deze kunnen dan gemirrored worden, of in een willekeurige raid gezet worden. Deze pool werkt ongeveer hetzelfde als bij LVM. Er is een pool met data beschikbaar en deze kan vervolgens weer gesplitst worden in datasets. Elke dataset heeft een aantal properties. Veel opties die bij andere dingen als mount opties in de fstab staan zijn in ZFS properties (mountpoint/extended attributes/atime/compressie). Er is ook een ZFS service en die regelt bij het opstarten alles zelf met betrekking tot mounten en sharen van file systems, dus er is niets van zfs te zien in /etc/fstab.<br />
<br />
== Raid Configuratie ==<br />
<br />
ZFS draait in een zogehete raidz2. Dit is in feite een raid 6 met wat extra voordelen, vanwege de integratie. Raidz's hebben geen last van het zogeheten [http://www.raid-recovery-guide.com/raid5-write-hole.aspx Write Hole] probleem. Bij een raidz2/raid6 kunnen er 2 disks uitvallen voordat dataverlies optreed.<br />
<br />
== Versies ==<br />
<br />
ZFSonLinux is een aparte kernel module en er komen geregeld nieuwe versies uit. De updates zijn tamelijk grondig, dus het is verstandig niet direct te upgraden zodra er een nieuwe release uit is. Op moment van schrijven draait Haskell ZoL 0.6.3-1 en Max draait 0.6.3. Nieuwe versies zijn altijd backwards compatible. Ze bieden echter wel de optie aan om de pool te upgraden naar de nieuwe versies, zodat er gebruik gemaakt kan worden van nieuwe functionaliteit. Wees dus terughoudend met het upgraden van de pool. Het is ook handig om de github, te vinden op [https://github.com/zfsonlinux/zfs/issues https://github.com/zfsonlinux/zfs/issues], in de gaten te houden om te kijken of er niet al te veel problemen zijn met de nieuwe versies.<br />
<br />
Na het updaten van ZFS of de kernel kan het nog wel eens gebeuren dat de package manager de nieuwe modules niet goed build en dat dit handmatig gebeuren moet. Dit gebeurd met de volgende commandos. Na het builden moet de zpool nog handmatig geimporteerd worden, dus schrik niet als je geen pools ziet.<br />
<br />
dkms install spl/<VERSION><br />
dkms install zfs/<VERSION><br />
<br />
Waar &lt;VERSION&gt; de versie van zfs is, dus bv 0.6.5.<br />
<br />
== Blocksize problemen ==<br />
<br />
Het aanmaken van de raidz6 pool is gebeurd met 4 sas schijven + 2 dummy's. De dummy's zijn later vervangen door 2 seagate's. De sas schijven hebben echter een blocksize van 512 en de pool heeft daardoor ook een blocksize van 512 gekregen. De seagates hebben echter een blocksize van 4096, waardoor write amplification optreed. Andersom zou dit geen probleem zijn. De write performance van de pool is hierdoor drastisch lager, potentieel 8x. Of de pool moet opnieuw gemaakt worden, of de seagate's moeten worden vervangen door schijven met een physical block size van 512 byte.<br />
<br />
== Caching ==<br />
<br />
ZFS heeft eigen caching mechanismes die buiten de linux page cache om gaat. Er zijn 2 belangrijke caches die belangrijk zijn. De ram caching. Deze heet de ARC en is ingesteld op 4GB. Daarnaast wordt er aan write caching gedaan. Data wordt eerst naar SSD geschreven en dan pas naar HDD. Deze write cache heet de ZIL (ZFS Intent Log). Statistieken over o.a. deze caches kunnen gevonden worden in `/proc/spl/kstat/zfs`<br />
<br />
<br />
<br />
== Do's and Don't ==<br />
<br />
=== Do's ===<br />
<br />
*De man pages van de commando's zfs en zpool zijn zeer uitgebreid. In het geval dat je niet helemaal weet hoe iets werkt, kijk eerst in de man page.<br />
*Er is een stuk over ZFS in de sysop inwerking, te vinden op [https://home.a-eskwadraat.nl/~sysop/inwerking/inwerking.pdf https://home.a-eskwadraat.nl/~sysop/inwerking/inwerking.pdf], dit is een goede start om een beetje bekend te raken met ZFS.<br />
<br />
man zpool<br />
man zfs<br />
<br />
=== Dont's ===<br />
<br />
*Wees voorzichting met zfs destroy, dubbelcheck altijd als je iets wilt verwijderen.<br />
*Als je met disks bezig bent, werkt altijd met /dev/disk/by-id/.. en niet met kale /dev/sda e.d.<br />
*Doe nooit iets met zpool labelclear, dit doet enge dingen met je partities.<br />
*Wees voorzichtig met het upgraden van ZFS.<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/ZFSZFS2015-12-30T16:39:59Z<p>Johand: ` `</p>
<hr />
<div>{{DISPLAYTITLE:ZFS}} [http://en.wikipedia.org/wiki/ZFS ZFS] is het file system dat gebruikt wordt om alle actieve data in op te slaan op [[Haskell|Haskell]]. Oorspronkelijk is het ontwikkeld door Sun Microsystems voor [http://en.wikipedia.org/wiki/Solaris_(operating_system) Solaris]. Vervolgens is het geport naar onder andere [https://wiki.freebsd.org/ZFS FreeBSD] en [http://zfsonlinux.org/ Linux]. Omdat het ontwikkeld is onder de [http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License CDDL] license en daarom is [http://zfsonlinux.org/ ZFS on Linux] geen onderdeel van de kernel, maar een losse module die via dkms apart ingeladen moet worden. Op [[Haskell|Haskell]] draait ZFS dus ook niet voor zijn root partitie, maar alleen voor data partities. Het zou anders kunnen dat bij een kernel of zfs update de kernel modules niet goed gebouwd worden je uberhaupt niet kan booten en dit is vrij problematisch.<br />
<br />
== Volume Manager vs File System ==<br />
<br />
ZFS is niet alleen een file system, het is ook een volume manager, zoals [http://en.wikipedia.org/wiki/Logical_Volume_Manager_(Linux) LVM]. Het is belangrijk om dit verschil tussen deze 2 lagen in het achterhoofd te houden. De bovenste laag heet bij ZFS de pool. De pool bestaat uit een aantal disks. Deze kunnen dan gemirrored worden, of in een willekeurige raid gezet worden. Deze pool werkt ongeveer hetzelfde als bij LVM. Er is een pool met data beschikbaar en deze kan vervolgens weer gesplitst worden in datasets. Elke dataset heeft een aantal properties. Veel opties die bij andere dingen als mount opties in de fstab staan zijn in ZFS properties (mountpoint/extended attributes/atime/compressie). Er is ook een ZFS service en die regelt bij het opstarten alles zelf met betrekking tot mounten en sharen van file systems, dus er is niets van zfs te zien in /etc/fstab.<br />
<br />
== Raid Configuratie ==<br />
<br />
ZFS draait in een zogehete raidz2. Dit is in feite een raid 6 met wat extra voordelen, vanwege de integratie. Raidz's hebben geen last van het zogeheten [http://www.raid-recovery-guide.com/raid5-write-hole.aspx Write Hole] probleem. Bij een raidz2/raid6 kunnen er 2 disks uitvallen voordat dataverlies optreed.<br />
<br />
== Versies ==<br />
<br />
ZFSonLinux is een aparte kernel module en er komen geregeld nieuwe versies uit. De updates zijn tamelijk grondig, dus het is verstandig niet direct te upgraden zodra er een nieuwe release uit is. Op moment van schrijven draait Haskell ZoL 0.6.3-1 en Max draait 0.6.3. Nieuwe versies zijn altijd backwards compatible. Ze bieden echter wel de optie aan om de pool te upgraden naar de nieuwe versies, zodat er gebruik gemaakt kan worden van nieuwe functionaliteit. Wees dus terughoudend met het upgraden van de pool. Het is ook handig om de github, te vinden op [https://github.com/zfsonlinux/zfs/issues https://github.com/zfsonlinux/zfs/issues], in de gaten te houden om te kijken of er niet al te veel problemen zijn met de nieuwe versies.<br />
<br />
== Blocksize problemen ==<br />
<br />
Het aanmaken van de raidz6 pool is gebeurd met 4 sas schijven + 2 dummy's. De dummy's zijn later vervangen door 2 seagate's. De sas schijven hebben echter een blocksize van 512 en de pool heeft daardoor ook een blocksize van 512 gekregen. De seagates hebben echter een blocksize van 4096, waardoor write amplification optreed. Andersom zou dit geen probleem zijn. De write performance van de pool is hierdoor drastisch lager, potentieel 8x. Of de pool moet opnieuw gemaakt worden, of de seagate's moeten worden vervangen door schijven met een physical block size van 512 byte.<br />
<br />
== Caching ==<br />
<br />
ZFS heeft eigen caching mechanismes die buiten de linux page cache om gaat. Er zijn 2 belangrijke caches die belangrijk zijn. De ram caching. Deze heet de ARC en is ingesteld op 4GB. Daarnaast wordt er aan write caching gedaan. Data wordt eerst naar SSD geschreven en dan pas naar HDD. Deze write cache heet de ZIL (ZFS Intent Log). Statistieken over o.a. deze caches kunnen gevonden worden in `/proc/spl/kstat/zfs`<br />
<br />
<br />
<br />
== Do's and Don't ==<br />
<br />
=== Do's ===<br />
<br />
De man pages van de commando's zfs en zpool zijn zeer uitgebreid. In het geval dat je niet helemaal weet hoe iets werkt, kijk eerst in de man page.<br />
<br />
man zpool<br />
man zfs<br />
<br />
=== Dont's ===<br />
<br />
*Wees voorzichting met zfs destroy, dubbelcheck altijd als je iets wilt verwijderen.<br />
*Als je met disks bezig bent, werkt altijd met /dev/disk/by-id/.. en niet met kale /dev/sda e.d.<br />
*Doe nooit iets met zpool labelclear, dit doet enge dingen met je partities.<br />
*Wees voorzichtig met het upgraden van ZFS.<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/MaxMax2015-12-30T14:57:41Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:max}} '''max''' was van 2007 tot [[Haskell|haskell]] de hoofdserver ([[Square|square]]) van A–Eskwadraat. Hij is vernoemd naar de Duitse fysicus [http://nl.wikipedia.org/wiki/Max_Planck Max Planck].<br />
<br />
== Software ==<br />
<br />
Net als de [[Workstations|workstations]] draait max Centos 7. Op dit moment staan er alleen backups op en is het een hele kale Centos 7, dus hij hangt ook niet in salt o.i.d.<br />
<br />
== Hardware ==<br />
<br />
In max zit een [http://ark.intel.com/products/28033/Intel-Xeon-Processor-X3210-(8M-Cache-2_13-GHz-1066-MHz-FSB) Xeon X3210] met een kloksnelheid van 2.13GHz en 4GB DDR2 RAM met een snelheid van 667MHz.<br />
<br />
=== Hard Disks ===<br />
<br />
Op het moment van schrijven zitten er vier hard disks in max. De root staat op een deel van de 2 schijven in een raid-0. De rest van deze 2 schijven + de andere 2 zitten in een raidz1 (raid-5).<br />
<br />
==== SATA II vs. SATA I ====<br />
<br />
Quote van [http://www.wdc.com/en/ Western Digital]:<br />
<br />
:Our Second Generation Serial ATA hard drives use autospeed negotiation. This enables our Second Generation Serial ATA hard drives to automatically detect the motherboard data transfer rate, making it backward compatible with First Generation Serial ATA data transfer rates. However, because this technology is so new, some older First Generation Serial ATA controllers are unable to support autospeed negotiation and cannot recognize the drive. This “drive not detected” condition occurs when a chipset is incapable of correctly negotiating the data transfer speed with a Second Generation Serial ATA hard drive.<br />
<br />
De oplossing: een SATA II schijf jumperen om 'm te forceren te werken in SATA I mode.<br />
[[Category:Hardware]] [[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BackupBackup2015-12-30T14:30:34Z<p>Johand: </p>
<hr />
<div>Geregeld worden er '''backups''' gemaakt van een groot deel van het systeem. Hier vallen onder andere de home directories en virtuele machines onder.<br />
<br />
== Interne backups ==<br />
<br />
De interne backups zijn bedoeld om bestanden terug te kunnen halen die per ongeluk verwijderd zijn. Elke 4 uur, met middernacht als offset, wordt er een recursieve snapshot gemaakt van alle data. Deze 4 uurlijkse snapshots worden, op die van middernacht na, 2 dagen bewaard. De snapshots van middernacht worden standaard 2 weken bewaard, met enkele uitzonderingen zoals de home directories. Deze uitzonderingen plus hun retention tijd staan op haskell in `/etc/cron.daily/managesnapshot`.<br />
<br />
Deze 4 uurlijkse backups worden direct gesynced naar de on-site backup in de vorm van max.<br />
<br />
Interne backups kunnen makkelijk teruggehaald worden. In het geval van een dataset is er in de root van deze dataset een onzichtbare map .zfs. In het geval van de home kan de staat van 20 november 2015 teruggevonden worden in `/srv/home/.zfs/snapshot/2015112000`. Dit kan alleen op haskell gedaan worden aangezien deze map niet bereikbaar is over NFS. Iets vergelijkbaars kan gedaan wordne met zvol's. Eerst moet echter de property snapdev op visible gezet worden in plaats van hidden en daarna zijn de snapshots van de zvols zichtbaar in `/dev`. Snapshots zijn read-only, dus als je een zvol probeert te mounten die dirty is, dan werkt dit niet als er ext4 op de zvol staat. Ext4 wil bij het recoveren namelijk schrijven, wat niet kan. In een dergelijke situatie kan het vaak handig zijn om een snapshot te klonen en dan te mounten. Met xfs is dit niet nodig.<br />
<br />
== Off-site backups ==<br />
<br />
We slaan de data ook off-site op bij de universiteit. Dit is een virtuele machine met de naam [[Claude|claude]]. Dit gebeurd vanaf max, aangezien daar een 1:1 kopie staat van de data en op deze manier wordt haskell ontlast. De backups worden vanaf [https://mediawiki.a-eskwadraat.nl/wiki/Claude claude] gepulled vanaf max en door max eerst ge-gzipped en ge-encrypt, zodat de universiteit niet bij onze data kan. Naar [https://mediawiki.a-eskwadraat.nl/wiki/Claude claude] wordt elke eerste dag van de maand een complete kopie gedumped en voor de rest van de maand worden incrementele dumps gemaakt.<br />
<br />
== Relevante scripts ==<br />
<br />
De volgende scripts en crons die te maken hebben met backups zijn allemaal in gebruik.<br />
<br />
*`/usr/local/bin/backupscript` op Haskell maakt elke 4 uur (door `/etc/cron.d/autobackup`) een snapshot en stuurt deze direct naar max.<br />
*`/etc/cron.daily/cleansnapshots` draait op zowel Max als Haskell en ruimt elke dag oude snapshots op. Deze file is identiek op beide machines, dus aanpassingen moeten gesynced worden.<br />
*`/usr/local/bin/pullbackups` op [https://mediawiki.a-eskwadraat.nl/wiki/Claude claude] pullt backups van Max en slaat deze op.<br />
*`/usr/local/bin/cleanbackups`op [https://mediawiki.a-eskwadraat.nl/wiki/Claude claude] ruimt oude snapshots op als de ruimte (2TB) vol dreigt te raken. Vol is >90%. Dit is een cron die elke 5 minuten checkt. Mocht er iets fout gaan zoals dat er bij het opruimen niet tenminste 1 volledige backup altijd bewaard blijft, dan mailt deze dit. Het gebeurd nog wel eens dat de nfs share van de universiteit eruit knalt, en dan flipt dit script ook.<br />
<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BindfsBindfs2015-06-03T14:03:31Z<p>Johand: </p>
<hr />
<div>Op een aantal plekken op het A-Eskwadraat systeem wordt [http://bindfs.org/ BindFS] gebruikt om permissies van commissies e.d. goed te houden. Eerst werd dit gedaan door de '''umask''' op ''0002'' te zetten, waardoor bestanden en directories altijd group writeable zijn. Dit gaat echter nog altijd fout in een aantal scenario's.<br />
<br />
<br />
<br />
*Sommige programma's zoals google-chrome downloaden bestanden altijd met rechten 640 als user:primary-group, ongeacht umask en of de directory de set group-id bit heeft. Bij het downloaden van bestanden direct naar een comissiemap gaat dit dan fout.<br />
*Een mv is in feite een rename en daarbij worden de rechten e.d. niet aangepast. Als iemand een file mv'ed van zijn homedir naar het commissieaccount heeft hij dus nog de oude rechten en kan de commissie er niet bij.<br />
*Bij een cp wordt er wel gekeken naar zaken als setgid bits, maar worden de rechten wel meegekopieerd, wat een probleem kan zijn als het origineel niet group-writeable is.<br />
<br />
De enige manier om bovenstaande problemen structureel op te lossen is om deze permissies hard op file system niveau af te dwingen. Hiervoor wordt [http://bindfs.org/ BindFS] gebruikt. Dit is een [http://fuse.sourceforge.net/ Fuse] file system waarmee een directory op een andere plek gemount kan worden, net zoals bij ''mount --bind'', maar waarbij de permissies ook nog aangepast kunnen worden. Om echter te zorgen dat de permissies van bestanden dynamisch aangepast worden afhankelijk van de locatie was het echter nodig om [http://bindfs.org/ BindFS] te patchen.<br />
<br />
== Gebruikte opties van BindFS ==<br />
<br />
Als we kijken naar de /etc/fstab van een systeem dat [http://bindfs.org/ BindFS] gebruikt zien we de volgende opties.<br />
<br />
*chmod-filter=g+rwD: Zorgt ervoor dat als er een chmod plaats vind op een file altijd de bits g+rw voor files en g+rwx voor directories geset worden. Een chmod 600 wordt dan bijvoorbeeld uitgevoerd als chmod 660 op de achtergrond.<br />
*create-with-perms=g+rwD: Permissies worden aangemaakt met g+rwD rechten.<br />
*perms=g+rwD: Bestaande bestanden worden gepresenteerd alsof ze g+rwD rechten hebben, ook al hoeft dat op de originele locatie niet zo te zijn.<br />
*chgrp-ignore: Negeer chgrp commando's. Dit is nodig omdat programma's als mv of google-chrome anders handmatig de group verkeerd zetten. Dit heeft wel als side effect dat handmatig rechten goedzetten dus ook niet meer kan.<br />
*nonempty: Zorgt ervoor dat [http://fuse.sourceforge.net/ Fuse] de directory in een niet lege directory kan mounten.<br />
*noauto: Eerst moeten de home directories in /mnt/home gemount worden, voordat [http://bindfs.org/ BindFS] deze weer in /home kan mounten. Dit wordt gedaan door het script /usr/local/sbin/mount-dirs dat via een service gerund wordt. Deze service start pas nadat netwerk-file systems gemount zijn.<br />
<br />
== Custom BindFS patch ==<br />
<br />
Met BindFS is het mogelijk om een enkele user en group te forcen, maar in ons geval willen we dit dynamisch doen, afhankelijk van de locatie van het bestand. Er is dus al code om een group-id te force'n, dus het enige wat gedaan moet worden is dit dynamisch te maken. Allereerst wordt bij het opstarten gekeken of de destination van de mount /home/iba, /home/cies, /home/bestuur of /home/extern is en alleen dan gebruiken we permission enforcement (settings.use_permission_enforcement). Er is gekozen om 4 aparte mountpoints te maken, zodat mv's nu cross-file systems zijn en dus geen rename meer zijn. Verder willen we ook geen permissies enforcen op de /home. Daarna wordt in de chown_new_file functie gekeken of de settings.use_permission_enforcement bit geset is en zoja, dan kijken we naar de directory van de file met behulp van een regex en zoeken we de bijbehorende group-id. Hierbij wordt als vuistregel gebruikt dat de naam van de top directory ook de group-name is. Dit levert problemen op als de naam van de homedir van een cie anders is dan de group-name.<br />
<pre>@@ -63,6 +63,8 @@<br />
#ifdef HAVE_SETXATTR<br />
#include <sys/xattr.h><br />
#endif<br />
+#include <linux/limits.h><br />
+#include <regex.h><br />
<br />
#include <fuse.h><br />
#include <fuse_opt.h><br />
@@ -141,6 +143,9 @@ static struct Settings {<br />
int ctime_from_mtime;<br />
int hide_hard_links;<br />
<br />
+ //Custom made for sysop<br />
+ int use_permission_enforcement;<br />
+<br />
} settings;<br />
<br />
<br />
@@ -306,6 +311,41 @@ static int getattr_common(const char *pr<br />
return 0;<br />
}<br />
<br />
+int get_gid(const char *path) {<br />
+<br />
+ regex_t regex;<br />
+ int reti;<br />
+<br />
+ regmatch_t matches[2];<br />
+<br />
+// reti = regcomp(&regex,"^/home/(cies|extern|iba|bestuur)/([^/]+)", REG_EXTENDED);<br />
+ reti = regcomp(&regex,"^([^/]+)", REG_EXTENDED);<br />
+ if (reti) {<br />
+ fprintf(stderr, "Could not compile regex\n");<br />
+ regfree(&regex);<br />
+ return -1;<br />
+ }<br />
+ reti = regexec(&regex, path, 2, matches, 0);<br />
+ int return_value = -1;<br />
+ if (!reti) {<br />
+ int match_size = matches[1].rm_eo - matches[1].rm_so;<br />
+ char *matchgroup = malloc(sizeof(char) * (1+match_size));<br />
+ matchgroup[match_size] = '\0';<br />
+ memcpy(matchgroup,&path[matches[1].rm_so],match_size);<br />
+ struct group *group_info = getgrnam(matchgroup);<br />
+ if (group_info == NULL) {<br />
+ return_value = -1;<br />
+ } else {<br />
+ return_value = group_info->gr_gid;<br />
+ }<br />
+<br />
+ free(matchgroup);<br />
+ }<br />
+ regfree(&regex);<br />
+ return return_value;<br />
+}<br />
+<br />
+<br />
/* FIXME: another thread may race to see the old owner before the chown is done.<br />
Is there a scenario where this compromises security? Or application correctness? */<br />
static void chown_new_file(const char *path, struct fuse_context *fc, int (*chown_func)(const char*, uid_t, gid_t))<br />
@@ -339,6 +379,14 @@ static void chown_new_file(const char *p<br />
if (settings.create_for_gid&nbsp;!= -1)<br />
file_group = settings.create_for_gid;<br />
<br />
+ //printf("Old file permission:&nbsp;%d&nbsp;%d\n",settings.use_permission_enforcement,file_group);<br />
+ if (settings.use_permission_enforcement) {<br />
+ <br />
+ int new_gid = get_gid(path);<br />
+ //printf("New file permssion:&nbsp;%d\n",new_gid);<br />
+ file_group = new_gid;<br />
+ }<br />
+<br />
if ((file_owner&nbsp;!= -1) || (file_group&nbsp;!= -1)) {<br />
if (chown_func(path, file_owner, file_group) == -1) {<br />
DPRINTF("Failed to chown new file or directory (%d)", errno);<br />
@@ -1670,6 +1718,13 @@ int main(int argc, char *argv[])<br />
bindfs_oper.listxattr = NULL;<br />
bindfs_oper.removexattr = NULL;<br />
}<br />
+ if (strcmp(settings.mntdest,"/home/iba") || <br />
+ strcmp(settings.mntdest,"/home/cies") ||<br />
+ strcmp(settings.mntdest,"/home/bestuur") ||<br />
+ strcmp(settings.mntdest,"/home/extern")) {<br />
+ settings.use_permission_enforcement = 1;<br />
+ }<br />
+ <br />
<br />
/* fuse_main will daemonize by fork()'ing. The signal handler will persist. */<br />
setup_signal_handling();<br />
</pre><br />
<br />
De code is de vinden in /root/bindfs-1.12.6 op elke machine waar&nbsp;[http://bindfs.org/ BindFS] gebruikt wordt. De patch is te vinden in /root/bindfs.patch.<br />
<br />
== Compilatie, debuggen, deployment ==<br />
De code bevat een Makefile, dus kan gewoon gecompileerd worden met de standaard ./configure en make. De binary is een executable met de naam "bindfs". Als deze neergezet wordt in een locatie in het systeempath zoals /usr/bin/ wordt deze automatisch herkend en gebruikt als je als vstype fuse.bindfs opgeeft met mount.<pre>mount -t fuse.bindfs</pre><br />
Voor compilatie zijn een standaard c compiler (zowel gcc als clang werkt) nodig en de package fuse-devel. Indien gecompileerd wordt op een CentOS 7 machine dan is deze executable niet te gebruiken op CentOS 6 vanwege een verouderde libc versie, andersom werkt wel. De executable kan ook eenvoudig gedebugd worden door een handmatige mount te doen met de -D optie.<pre>/usr/bin/bindfs -d -o chmod-filter=g+rwD,create-with-perms=g+rwD,perms=g+rwD,chgrp-ignore,nonempty /mnt/home/ /home</pre><br />
<br />
In salt is de config te vinden in /srv/salt/centos7/homedirs. Dit is een losse state die het mounten van de homedirs via [http://bindfs.org/ BindFS] mogelijk maakt.<br />
<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BindfsBindfs2015-06-03T13:59:44Z<p>Johand: </p>
<hr />
<div>Op een aantal plekken op het A-Eskwadraat systeem wordt [http://bindfs.org/ BindFS] gebruikt om permissies van commissies e.d. goed te houden. Eerst werd dit gedaan door de '''umask''' op ''0002'' te zetten, waardoor bestanden en directories altijd group writeable zijn. Dit gaat echter nog altijd fout in een aantal scenario's.<br />
<br />
<br />
<br />
*Sommige programma's zoals google-chrome downloaden bestanden altijd met rechten 640 als user:primary-group, ongeacht umask en of de directory de set group-id bit heeft. Bij het downloaden van bestanden direct naar een comissiemap gaat dit dan fout.<br />
*Een mv is in feite een rename en daarbij worden de rechten e.d. niet aangepast. Als iemand een file mv'ed van zijn homedir naar het commissieaccount heeft hij dus nog de oude rechten en kan de commissie er niet bij.<br />
*Bij een cp wordt er wel gekeken naar zaken als setgid bits, maar worden de rechten wel meegekopieerd, wat een probleem kan zijn als het origineel niet group-writeable is.<br />
<br />
De enige manier om bovenstaande problemen structureel op te lossen is om deze permissies hard op file system niveau af te dwingen. Hiervoor wordt [http://bindfs.org/ BindFS] gebruikt. Dit is een [http://fuse.sourceforge.net/ Fuse] file system waarmee een directory op een andere plek gemount kan worden, net zoals bij ''mount --bind'', maar waarbij de permissies ook nog aangepast kunnen worden. Om echter te zorgen dat de permissies van bestanden dynamisch aangepast worden afhankelijk van de locatie was het echter nodig om [http://bindfs.org/ BindFS] te patchen.<br />
<br />
== Gebruikte opties van BindFS ==<br />
<br />
Als we kijken naar de /etc/fstab van een systeem dat [http://bindfs.org/ BindFS] gebruikt zien we de volgende opties.<br />
<br />
*chmod-filter=g+rwD: Zorgt ervoor dat als er een chmod plaats vind op een file altijd de bits g+rw voor files en g+rwx voor directories geset worden. Een chmod 600 wordt dan bijvoorbeeld uitgevoerd als chmod 660 op de achtergrond.<br />
*create-with-perms=g+rwD: Permissies worden aangemaakt met g+rwD rechten.<br />
*perms=g+rwD: Bestaande bestanden worden gepresenteerd alsof ze g+rwD rechten hebben, ook al hoeft dat op de originele locatie niet zo te zijn.<br />
*chgrp-ignore: Negeer chgrp commando's. Dit is nodig omdat programma's als mv of google-chrome anders handmatig de group verkeerd zetten. Dit heeft wel als side effect dat handmatig rechten goedzetten dus ook niet meer kan.<br />
*nonempty: Zorgt ervoor dat [http://fuse.sourceforge.net/ Fuse] de directory in een niet lege directory kan mounten.<br />
*noauto: Eerst moeten de home directories in /mnt/home gemount worden, voordat [http://bindfs.org/ BindFS] deze weer in /home kan mounten. Dit wordt gedaan door het script /usr/local/sbin/mount-dirs dat via een service gerund wordt. Deze service start pas nadat netwerk-file systems gemount zijn.<br />
<br />
== Custom BindFS patch ==<br />
<br />
Met BindFS is het mogelijk om een enkele user en group te forcen, maar in ons geval willen we dit dynamisch doen, afhankelijk van de locatie van het bestand. Er is dus al code om een group-id te force'n, dus het enige wat gedaan moet worden is dit dynamisch te maken. Allereerst wordt bij het opstarten gekeken of de destination van de mount /home/iba, /home/cies, /home/bestuur of /home/extern is en alleen dan gebruiken we permission enforcement (settings.use_permission_enforcement). Er is gekozen om 4 aparte mountpoints te maken, zodat mv's nu cross-file systems zijn en dus geen rename meer zijn. Verder willen we ook geen permissies enforcen op de /home. Daarna wordt in de chown_new_file functie gekeken of de settings.use_permission_enforcement bit geset is en zoja, dan kijken we naar de directory van de file met behulp van een regex en zoeken we de bijbehorende group-id. Hierbij wordt als vuistregel gebruikt dat de naam van de top directory ook de group-name is. Dit levert problemen op als de naam van de homedir van een cie anders is dan de group-name.<br />
<pre><br />
@@ -63,6 +63,8 @@<br />
#ifdef HAVE_SETXATTR<br />
#include <sys/xattr.h><br />
#endif<br />
+#include <linux/limits.h><br />
+#include <regex.h><br />
<br />
#include <fuse.h><br />
#include <fuse_opt.h><br />
@@ -141,6 +143,9 @@ static struct Settings {<br />
int ctime_from_mtime;<br />
int hide_hard_links;<br />
<br />
+ //Custom made for sysop<br />
+ int use_permission_enforcement;<br />
+<br />
} settings;<br />
<br />
<br />
@@ -306,6 +311,41 @@ static int getattr_common(const char *pr<br />
return 0;<br />
}<br />
<br />
+int get_gid(const char *path) {<br />
+<br />
+ regex_t regex;<br />
+ int reti;<br />
+<br />
+ regmatch_t matches[2];<br />
+<br />
+// reti = regcomp(&regex,"^/home/(cies|extern|iba|bestuur)/([^/]+)", REG_EXTENDED);<br />
+ reti = regcomp(&regex,"^([^/]+)", REG_EXTENDED);<br />
+ if (reti) {<br />
+ fprintf(stderr, "Could not compile regex\n");<br />
+ regfree(&regex);<br />
+ return -1;<br />
+ }<br />
+ reti = regexec(&regex, path, 2, matches, 0);<br />
+ int return_value = -1;<br />
+ if (!reti) {<br />
+ int match_size = matches[1].rm_eo - matches[1].rm_so;<br />
+ char *matchgroup = malloc(sizeof(char) * (1+match_size));<br />
+ matchgroup[match_size] = '\0';<br />
+ memcpy(matchgroup,&path[matches[1].rm_so],match_size);<br />
+ struct group *group_info = getgrnam(matchgroup);<br />
+ if (group_info == NULL) {<br />
+ return_value = -1;<br />
+ } else {<br />
+ return_value = group_info->gr_gid;<br />
+ }<br />
+<br />
+ free(matchgroup);<br />
+ }<br />
+ regfree(&regex);<br />
+ return return_value;<br />
+}<br />
+<br />
+<br />
/* FIXME: another thread may race to see the old owner before the chown is done.<br />
Is there a scenario where this compromises security? Or application correctness? */<br />
static void chown_new_file(const char *path, struct fuse_context *fc, int (*chown_func)(const char*, uid_t, gid_t))<br />
@@ -339,6 +379,14 @@ static void chown_new_file(const char *p<br />
if (settings.create_for_gid != -1)<br />
file_group = settings.create_for_gid;<br />
<br />
+ //printf("Old file permission: %d %d\n",settings.use_permission_enforcement,file_group);<br />
+ if (settings.use_permission_enforcement) {<br />
+ <br />
+ int new_gid = get_gid(path);<br />
+ //printf("New file permssion: %d\n",new_gid);<br />
+ file_group = new_gid;<br />
+ }<br />
+<br />
if ((file_owner != -1) || (file_group != -1)) {<br />
if (chown_func(path, file_owner, file_group) == -1) {<br />
DPRINTF("Failed to chown new file or directory (%d)", errno);<br />
@@ -1670,6 +1718,13 @@ int main(int argc, char *argv[])<br />
bindfs_oper.listxattr = NULL;<br />
bindfs_oper.removexattr = NULL;<br />
}<br />
+ if (strcmp(settings.mntdest,"/home/iba") || <br />
+ strcmp(settings.mntdest,"/home/cies") ||<br />
+ strcmp(settings.mntdest,"/home/bestuur") ||<br />
+ strcmp(settings.mntdest,"/home/extern")) {<br />
+ settings.use_permission_enforcement = 1;<br />
+ }<br />
+ <br />
<br />
/* fuse_main will daemonize by fork()'ing. The signal handler will persist. */<br />
setup_signal_handling();<br />
</pre><br />
<br />
TODO: Locatie waar de code terug te vinden is. (Wat is een handige plek?)<br />
<br />
== Compilatie, debuggen, deployment ==<br />
De code bevat een Makefile, dus kan gewoon gecompileerd worden met de standaard ./configure en make. De binary is een executable met de naam "bindfs". Als deze neergezet wordt in een locatie in het systeempath zoals /usr/bin/ wordt deze automatisch herkend en gebruikt als je als vstype fuse.bindfs opgeeft met mount.<pre>mount -t fuse.bindfs</pre><br />
Voor compilatie zijn een standaard c compiler (zowel gcc als clang werkt) nodig en de package fuse-devel. Indien gecompileerd wordt op een CentOS 7 machine dan is deze executable niet te gebruiken op CentOS 6 vanwege een verouderde libc versie, andersom werkt wel. De executable kan ook eenvoudig gedebugd worden door een handmatige mount te doen met de -D optie.<pre>/usr/bin/bindfs -d -o chmod-filter=g+rwD,create-with-perms=g+rwD,perms=g+rwD,chgrp-ignore,nonempty /mnt/home/ /home</pre><br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BindfsBindfs2015-06-03T12:49:25Z<p>Johand: </p>
<hr />
<div>Op een aantal plekken op het A-Eskwadraat systeem wordt [http://bindfs.org/ BindFS] gebruikt om permissies van commissies e.d. goed te houden. Eerst werd dit gedaan door de '''umask''' op ''0002'' te zetten, waardoor bestanden en directories altijd group writeable zijn. Dit gaat echter nog altijd fout in een aantal scenario's.<br />
<br />
<br />
<br />
*Sommige programma's zoals google-chrome downloaden bestanden altijd met rechten 640 als user:primary-group, ongeacht umask en of de directory de set group-id bit heeft. Bij het downloaden van bestanden direct naar een comissiemap gaat dit dan fout.<br />
*Een mv is in feite een rename en daarbij worden de rechten e.d. niet aangepast. Als iemand een file mv'ed van zijn homedir naar het commissieaccount heeft hij dus nog de oude rechten en kan de commissie er niet bij.<br />
*Bij een cp wordt er wel gekeken naar zaken als setgid bits, maar worden de rechten wel meegekopieerd, wat een probleem kan zijn als het origineel niet group-writeable is.<br />
<br />
De enige manier om bovenstaande problemen structureel op te lossen is om deze permissies hard op file system niveau af te dwingen. Hiervoor wordt [http://bindfs.org/ BindFS] gebruikt. Dit is een [http://fuse.sourceforge.net/ Fuse] file system waarmee een directory op een andere plek gemount kan worden, net zoals bij ''mount --bind'', maar waarbij de permissies ook nog aangepast kunnen worden. Om echter te zorgen dat de permissies van bestanden dynamisch aangepast worden afhankelijk van de locatie was het echter nodig om [http://bindfs.org/ BindFS] te patchen.<br />
<br />
== Gebruikte opties van BindFS ==<br />
<br />
Als we kijken naar de /etc/fstab van een systeem dat [http://bindfs.org/ BindFS] gebruikt zien we de volgende opties.<br />
<br />
*chmod-filter=g+rwD: Zorgt ervoor dat als er een chmod plaats vind op een file altijd de bits g+rw voor files en g+rwx voor directories geset worden. Een chmod 600 wordt dan bijvoorbeeld uitgevoerd als chmod 660 op de achtergrond.<br />
*create-with-perms=g+rwD: Permissies worden aangemaakt met g+rwD rechten.<br />
*perms=g+rwD: Bestaande bestanden worden gepresenteerd alsof ze g+rwD rechten hebben, ook al hoeft dat op de originele locatie niet zo te zijn.<br />
*chgrp-ignore: Negeer chgrp commando's. Dit is nodig omdat programma's als mv of google-chrome anders handmatig de group verkeerd zetten. Dit heeft wel als side effect dat handmatig rechten goedzetten dus ook niet meer kan.<br />
*nonempty: Zorgt ervoor dat [http://fuse.sourceforge.net/ Fuse] de directory in een niet lege directory kan mounten.<br />
*noauto: Eerst moeten de home directories in /mnt/home gemount worden, voordat [http://bindfs.org/ BindFS] deze weer in /home kan mounten. Dit wordt gedaan door het script /usr/local/sbin/mount-dirs dat via een service gerund wordt. Deze service start pas nadat netwerk-file systems gemount zijn.<br />
<br />
== Custom BindFS patch ==<br />
<br />
Met BindFS is het mogelijk om een enkele user en group te forcen, maar in ons geval willen we dit dynamisch doen, afhankelijk van de locatie van het bestand. Er is dus al code om een group-id te force'n, dus het enige wat gedaan moet worden is dit dynamisch te maken. Allereerst wordt bij het opstarten gekeken of de destination van de mount /home/iba, /home/cies, /home/bestuur of /home/extern is en alleen dan gebruiken we permission enforcement (settings.use_permission_enforcement). Er is gekozen om 4 aparte mountpoints te maken, zodat mv's nu cross-file systems zijn en dus geen rename meer zijn. Verder willen we ook geen permissies enforcen op de /home. Daarna wordt in de chown_new_file functie gekeken of de settings.use_permission_enforcement bit geset is en zoja, dan kijken we naar de directory van de file met behulp van een regex en zoeken we de bijbehorende group-id. Hierbij wordt als vuistregel gebruikt dat de naam van de top directory ook de group-name is. Dit levert problemen op als de naam van de homedir van een cie anders is dan de group-name.<br />
<pre>@@ -63,6 +63,8 @@<br />
#ifdef HAVE_SETXATTR<br />
#include <sys/xattr.h><br />
#endif<br />
+#include <linux/limits.h><br />
+#include <regex.h><br />
<br />
#include <fuse.h><br />
#include <fuse_opt.h><br />
@@ -141,6 +143,9 @@ static struct Settings {<br />
int ctime_from_mtime;<br />
int hide_hard_links;<br />
<br />
+ //Custom made for sysop<br />
+ int use_permission_enforcement;<br />
+<br />
} settings;<br />
<br />
<br />
@@ -306,6 +311,41 @@ static int getattr_common(const char *pr<br />
return 0;<br />
}<br />
<br />
+int get_gid(const char *path) {<br />
+<br />
+ regex_t regex;<br />
+ int reti;<br />
+<br />
+ regmatch_t matches[2];<br />
+<br />
+// reti = regcomp(&regex,"^/home/(cies|extern|iba|bestuur)/([^/]+)", REG_EXTENDED);<br />
+ reti = regcomp(&regex,"^([^/]+)", REG_EXTENDED);<br />
+ if (reti) {<br />
+ fprintf(stderr, "Could not compile regex\n");<br />
+ regfree(&regex);<br />
+ return -1;<br />
+ }<br />
+ reti = regexec(&regex, path, 2, matches, 0);<br />
+ int return_value = -1;<br />
+ if (!reti) {<br />
+ int match_size = matches[1].rm_eo - matches[1].rm_so;<br />
+ char *matchgroup = malloc(sizeof(char) * (1+match_size));<br />
+ matchgroup[match_size] = '\0';<br />
+ memcpy(matchgroup,&path[matches[1].rm_so],match_size);<br />
+ struct group *group_info = getgrnam(matchgroup);<br />
+ if (group_info == NULL) {<br />
+ return_value = -1;<br />
+ } else {<br />
+ return_value = group_info->gr_gid;<br />
+ }<br />
+<br />
+ free(matchgroup);<br />
+ }<br />
+ regfree(&regex);<br />
+ return return_value;<br />
+}<br />
+<br />
+<br />
/* FIXME: another thread may race to see the old owner before the chown is done.<br />
Is there a scenario where this compromises security? Or application correctness? */<br />
static void chown_new_file(const char *path, struct fuse_context *fc, int (*chown_func)(const char*, uid_t, gid_t))<br />
@@ -339,6 +379,14 @@ static void chown_new_file(const char *p<br />
if (settings.create_for_gid&nbsp;!= -1)<br />
file_group = settings.create_for_gid;<br />
<br />
+ //printf("Old file permission:&nbsp;%d&nbsp;%d\n",settings.use_permission_enforcement,file_group);<br />
+ if (settings.use_permission_enforcement) {<br />
+ <br />
+ int new_gid = get_gid(path);<br />
+ //printf("New file permssion:&nbsp;%d\n",new_gid);<br />
+ file_group = new_gid;<br />
+ }<br />
+<br />
if ((file_owner&nbsp;!= -1) || (file_group&nbsp;!= -1)) {<br />
if (chown_func(path, file_owner, file_group) == -1) {<br />
DPRINTF("Failed to chown new file or directory (%d)", errno);<br />
@@ -1670,6 +1718,13 @@ int main(int argc, char *argv[])<br />
bindfs_oper.listxattr = NULL;<br />
bindfs_oper.removexattr = NULL;<br />
}<br />
+ if (strcmp(settings.mntdest,"/home/iba") || <br />
+ strcmp(settings.mntdest,"/home/cies") ||<br />
+ strcmp(settings.mntdest,"/home/bestuur") ||<br />
+ strcmp(settings.mntdest,"/home/extern")) {<br />
+ settings.use_permission_enforcement = 1;<br />
+ }<br />
+ <br />
<br />
/* fuse_main will daemonize by fork()'ing. The signal handler will persist. */<br />
setup_signal_handling();<br />
</pre><br />
<br />
TODO: Locatie waar de code terug te vinden is. (Wat is een handige plek?)<br />
<br />
== Compilatie, debuggen, deployment ==<br />
De code bevat een Makefile, dus kan gewoon gecompileerd worden met de standaard ./configure en make. De binary is een executable met de naam "bindfs". Als deze neergezet wordt in een locatie in het systeempath zoals /usr/bin/ wordt deze automatisch herkend en gebruikt als je als vstype fuse.bindfs opgeeft met mount.<pre>mount -t fuse.bindfs</pre><br />
Voor compilatie zijn een standaard c compiler (zowel gcc als clang werkt) nodig en de package fuse-devel. Indien gecompileerd wordt op een CentOS 7 machine dan is deze executable niet te gebruiken op CentOS 6 vanwege een verouderde libc versie, andersom werkt wel. De executable kan ook eenvoudig gedebugd worden door een handmatige mount te doen met de -D optie.<pre>/usr/bin/bindfs -d -o chmod-filter=g+rwD,create-with-perms=g+rwD,perms=g+rwD,chgrp-ignore,nonempty /mnt/home/ /home</pre><br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BindfsBindfs2015-06-03T12:06:33Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:BindFS}} Op een aantal plekken op het A-Eskwadraat systeem wordt [http://bindfs.org/ BindFS] gebruikt om permissies van commissies e.d. goed te houden. Eerst werd dit gedaan door de '''umask''' op ''0002'' te zetten, waardoor bestanden en directories altijd group writeable zijn. Dit gaat echter nog altijd fout in een aantal scenario's.<br />
<br />
<br />
<br />
*Sommige programma's zoals google-chrome downloaden bestanden altijd met rechten 640 als user:primary-group, ongeacht umask en of de directory de set group-id bit heeft. Bij het downloaden van bestanden direct naar een comissiemap gaat dit dan fout.<br />
*Een mv is in feite een rename en daarbij worden de rechten e.d. niet aangepast. Als iemand een file mv'ed van zijn homedir naar het commissieaccount heeft hij dus nog de oude rechten en kan de commissie er niet bij.<br />
*Bij een cp wordt er wel gekeken naar zaken als setgid bits, maar worden de rechten wel meegekopieerd, wat een probleem kan zijn als het origineel niet group-writeable is.<br />
<br />
De enige manier om bovenstaande problemen structureel op te lossen is om deze permissies hard op file system niveau af te dwingen. Hiervoor wordt [http://bindfs.org/ BindFS] gebruikt. Dit is een [http://fuse.sourceforge.net/ Fuse] file system waarmee een directory op een andere plek gemount kan worden, net zoals bij ''mount --bind'', maar waarbij de permissies ook nog aangepast kunnen worden. Om echter te zorgen dat de permissies van bestanden dynamisch aangepast worden afhankelijk van de locatie was het echter nodig om [http://bindfs.org/ BindFS] te patchen.<br />
<br />
== Gebruikte opties van BindFS ==<br />
<br />
Als we kijken naar de /etc/fstab van een systeem dat [http://bindfs.org/ BindFS] gebruikt zien we de volgende opties.<br />
<br />
*chmod-filter=g+rwD: Zorgt ervoor dat als er een chmod plaats vind op een file altijd de bits g+rw voor files en g+rwx voor directories geset worden. Een chmod 600 wordt dan bijvoorbeeld uitgevoerd als chmod 660 op de achtergrond.<br />
*create-with-perms=g+rwD: Permissies worden aangemaakt met g+rwD rechten.<br />
*perms=g+rwD: Bestaande bestanden worden gepresenteerd alsof ze g+rwD rechten hebben, ook al hoeft dat op de originele locatie niet zo te zijn.<br />
*chgrp-ignore: Negeer chgrp commando's. Dit is nodig omdat programma's als mv of google-chrome anders handmatig de group verkeerd zetten. Dit heeft wel als side effect dat handmatig rechten goedzetten dus ook niet meer kan.<br />
*nonempty: Zorgt ervoor dat [http://fuse.sourceforge.net/ Fuse] de directory in een niet lege directory kan mounten.<br />
*noauto: Eerst moeten de home directories in /mnt/home gemount worden, voordat [http://bindfs.org/ BindFS] deze weer in /home kan mounten. Dit wordt gedaan door het script /usr/local/sbin/mount-dirs dat via een service gerund wordt. Deze service start pas nadat netwerk-file systems gemount zijn.<br />
<br />
== Custom BindFS patch ==<br />
<br />
Met BindFS is het mogelijk om een enkele user en group te forcen, maar in ons geval willen we dit dynamisch doen, afhankelijk van de locatie van het bestand. Er is dus al code om een group-id te force'n, dus het enige wat gedaan moet worden is dit dynamisch te maken. Allereerst wordt bij het opstarten gekeken of de destination van de mount /home/iba, /home/cies, /home/bestuur of /home/extern is en alleen dan gebruiken we permission enforcement (settings.use_permission_enforcement). Er is gekozen om 4 aparte mountpoints te maken, zodat mv's nu cross-file systems zijn en dus geen rename meer zijn. Verder willen we ook geen permissies enforcen op de /home. Daarna wordt in de chown_new_file functie gekeken of de settings.use_permission_enforcement bit geset is en zoja, dan kijken we naar de directory van de file met behulp van een regex en zoeken we de bijbehorende group-id. Hierbij wordt als vuistregel gebruikt dat de naam van de top directory ook de group-name is. Dit levert problemen op als de naam van de homedir van een cie anders is dan de group-name.<br />
<pre>@@ -63,6 +63,8 @@<br />
#ifdef HAVE_SETXATTR<br />
#include <sys/xattr.h><br />
#endif<br />
+#include <linux/limits.h><br />
+#include <regex.h><br />
<br />
#include <fuse.h><br />
#include <fuse_opt.h><br />
@@ -141,6 +143,9 @@ static struct Settings {<br />
int ctime_from_mtime;<br />
int hide_hard_links;<br />
<br />
+ //Custom made for sysop<br />
+ int use_permission_enforcement;<br />
+<br />
} settings;<br />
<br />
<br />
@@ -306,6 +311,41 @@ static int getattr_common(const char *pr<br />
return 0;<br />
}<br />
<br />
+int get_gid(const char *path) {<br />
+<br />
+ regex_t regex;<br />
+ int reti;<br />
+<br />
+ regmatch_t matches[2];<br />
+<br />
+// reti = regcomp(&regex,"^/home/(cies|extern|iba|bestuur)/([^/]+)", REG_EXTENDED);<br />
+ reti = regcomp(&regex,"^([^/]+)", REG_EXTENDED);<br />
+ if (reti) {<br />
+ fprintf(stderr, "Could not compile regex\n");<br />
+ regfree(&regex);<br />
+ return -1;<br />
+ }<br />
+ reti = regexec(&regex, path, 2, matches, 0);<br />
+ int return_value = -1;<br />
+ if (!reti) {<br />
+ int match_size = matches[1].rm_eo - matches[1].rm_so;<br />
+ char *matchgroup = malloc(sizeof(char) * (1+match_size));<br />
+ matchgroup[match_size] = '\0';<br />
+ memcpy(matchgroup,&path[matches[1].rm_so],match_size);<br />
+ struct group *group_info = getgrnam(matchgroup);<br />
+ if (group_info == NULL) {<br />
+ return_value = -1;<br />
+ } else {<br />
+ return_value = group_info->gr_gid;<br />
+ }<br />
+<br />
+ free(matchgroup);<br />
+ }<br />
+ regfree(&regex);<br />
+ return return_value;<br />
+}<br />
+<br />
+<br />
/* FIXME: another thread may race to see the old owner before the chown is done.<br />
Is there a scenario where this compromises security? Or application correctness? */<br />
static void chown_new_file(const char *path, struct fuse_context *fc, int (*chown_func)(const char*, uid_t, gid_t))<br />
@@ -339,6 +379,14 @@ static void chown_new_file(const char *p<br />
if (settings.create_for_gid&nbsp;!= -1)<br />
file_group = settings.create_for_gid;<br />
<br />
+ //printf("Old file permission:&nbsp;%d&nbsp;%d\n",settings.use_permission_enforcement,file_group);<br />
+ if (settings.use_permission_enforcement) {<br />
+ <br />
+ int new_gid = get_gid(path);<br />
+ //printf("New file permssion:&nbsp;%d\n",new_gid);<br />
+ file_group = new_gid;<br />
+ }<br />
+<br />
if ((file_owner&nbsp;!= -1) || (file_group&nbsp;!= -1)) {<br />
if (chown_func(path, file_owner, file_group) == -1) {<br />
DPRINTF("Failed to chown new file or directory (%d)", errno);<br />
@@ -1670,6 +1718,13 @@ int main(int argc, char *argv[])<br />
bindfs_oper.listxattr = NULL;<br />
bindfs_oper.removexattr = NULL;<br />
}<br />
+ if (strcmp(settings.mntdest,"/home/iba") || <br />
+ strcmp(settings.mntdest,"/home/cies") ||<br />
+ strcmp(settings.mntdest,"/home/bestuur") ||<br />
+ strcmp(settings.mntdest,"/home/extern")) {<br />
+ settings.use_permission_enforcement = 1;<br />
+ }<br />
+ <br />
<br />
/* fuse_main will daemonize by fork()'ing. The signal handler will persist. */<br />
setup_signal_handling();<br />
</pre><br />
<br />
TODO: Locatie waar de code terug te vinden is. (Wat is een handige plek?)<br />
<br />
== Compilatie, debuggen, deployment ==<br />
De code bevat een Makefile, dus kan gewoon gecompileerd worden met de standaard ./configure en make. De binary is een executable met de naam "bindfs". Als deze neergezet wordt in een locatie in het systeempath zoals /usr/bin/ wordt deze automatisch herkend en gebruikt als je als vstype fuse.bindfs opgeeft met mount.<pre>mount -t fuse.bindfs</pre><br />
Voor compilatie zijn een standaard c compiler (zowel gcc als clang werkt) nodig en de package fuse-devel. Indien gecompileerd wordt op een CentOS 7 machine dan is deze executable niet te gebruiken op CentOS 6 vanwege een verouderde libc versie, andersom werkt wel. De executable kan ook eenvoudig gedebugd worden door een handmatige mount te doen met de -D optie.<pre>/usr/bin/bindfs -d -o chmod-filter=g+rwD,create-with-perms=g+rwD,perms=g+rwD,chgrp-ignore,nonempty /mnt/home/ /home</pre><br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BindfsBindfs2015-06-03T12:05:34Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:BindFS}}<br />
Op een aantal plekken op het A-Eskwadraat systeem wordt [http://bindfs.org/ BindFS] gebruikt om permissies van commissies e.d. goed te houden. Eerst werd dit gedaan door de '''umask''' op ''0002'' te zetten, waardoor bestanden en directories altijd group writeable zijn. Dit gaat echter nog altijd fout in een aantal scenario's.<br />
<br />
<br />
<br />
*Sommige programma's zoals google-chrome downloaden bestanden altijd met rechten 640 als user:primary-group, ongeacht umask en of de directory de set group-id bit heeft. Bij het downloaden van bestanden direct naar een comissiemap gaat dit dan fout.<br />
*Een mv is in feite een rename en daarbij worden de rechten e.d. niet aangepast. Als iemand een file mv'ed van zijn homedir naar het commissieaccount heeft hij dus nog de oude rechten en kan de commissie er niet bij.<br />
*Bij een cp wordt er wel gekeken naar zaken als setgid bits, maar worden de rechten wel meegekopieerd, wat een probleem kan zijn als het origineel niet group-writeable is.<br />
<br />
De enige manier om bovenstaande problemen structureel op te lossen is om deze permissies hard op file system niveau af te dwingen. Hiervoor wordt [http://bindfs.org/ BindFS] gebruikt. Dit is een [http://fuse.sourceforge.net/ Fuse] file system waarmee een directory op een andere plek gemount kan worden, net zoals bij ''mount --bind'', maar waarbij de permissies ook nog aangepast kunnen worden. Om echter te zorgen dat de permissies van bestanden dynamisch aangepast worden afhankelijk van de locatie was het echter nodig om [http://bindfs.org/ BindFS] te patchen.<br />
<br />
== Gebruikte opties van BindFS ==<br />
<br />
Als we kijken naar de /etc/fstab van een systeem dat [http://bindfs.org/ BindFS] gebruikt zien we de volgende opties.<br />
<br />
*chmod-filter=g+rwD: Zorgt ervoor dat als er een chmod plaats vind op een file altijd de bits g+rw voor files en g+rwx voor directories geset worden. Een chmod 600 wordt dan bijvoorbeeld uitgevoerd als chmod 660 op de achtergrond.<br />
*create-with-perms=g+rwD: Permissies worden aangemaakt met g+rwD rechten.<br />
*perms=g+rwD: Bestaande bestanden worden gepresenteerd alsof ze g+rwD rechten hebben, ook al hoeft dat op de originele locatie niet zo te zijn.<br />
*chgrp-ignore: Negeer chgrp commando's. Dit is nodig omdat programma's als mv of google-chrome anders handmatig de group verkeerd zetten. Dit heeft wel als side effect dat handmatig rechten goedzetten dus ook niet meer kan.<br />
*nonempty: Zorgt ervoor dat [http://fuse.sourceforge.net/ Fuse] de directory in een niet lege directory kan mounten.<br />
*noauto: Eerst moeten de home directories in /mnt/home gemount worden, voordat [http://bindfs.org/ BindFS] deze weer in /home kan mounten. Dit wordt gedaan door het script /usr/local/sbin/mount-dirs dat via een service gerund wordt. Deze service start pas nadat netwerk-file systems gemount zijn.<br />
<br />
== Custom BindFS patch ==<br />
<br />
Met BindFS is het mogelijk om een enkele user en group te forcen, maar in ons geval willen we dit dynamisch doen, afhankelijk van de locatie van het bestand. Er is dus al code om een group-id te force'n, dus het enige wat gedaan moet worden is dit dynamisch te maken. Allereerst wordt bij het opstarten gekeken of de destination van de mount /home/iba, /home/cies, /home/bestuur of /home/extern is en alleen dan gebruiken we permission enforcement (settings.use_permission_enforcement). Er is gekozen om 4 aparte mountpoints te maken, zodat mv's nu cross-file systems zijn en dus geen rename meer zijn. Verder willen we ook geen permissies enforcen op de /home. Daarna wordt in de chown_new_file functie gekeken of de settings.use_permission_enforcement bit geset is en zoja, dan kijken we naar de directory van de file met behulp van een regex en zoeken we de bijbehorende group-id. Hierbij wordt als vuistregel gebruikt dat de naam van de top directory ook de group-name is. Dit levert problemen op als de naam van de homedir van een cie anders is dan de group-name.<br />
<pre>@@ -63,6 +63,8 @@<br />
#ifdef HAVE_SETXATTR<br />
#include <sys/xattr.h><br />
#endif<br />
+#include <linux/limits.h><br />
+#include <regex.h><br />
<br />
#include <fuse.h><br />
#include <fuse_opt.h><br />
@@ -141,6 +143,9 @@ static struct Settings {<br />
int ctime_from_mtime;<br />
int hide_hard_links;<br />
<br />
+ //Custom made for sysop<br />
+ int use_permission_enforcement;<br />
+<br />
} settings;<br />
<br />
<br />
@@ -306,6 +311,41 @@ static int getattr_common(const char *pr<br />
return 0;<br />
}<br />
<br />
+int get_gid(const char *path) {<br />
+<br />
+ regex_t regex;<br />
+ int reti;<br />
+<br />
+ regmatch_t matches[2];<br />
+<br />
+// reti = regcomp(&regex,"^/home/(cies|extern|iba|bestuur)/([^/]+)", REG_EXTENDED);<br />
+ reti = regcomp(&regex,"^([^/]+)", REG_EXTENDED);<br />
+ if (reti) {<br />
+ fprintf(stderr, "Could not compile regex\n");<br />
+ regfree(&regex);<br />
+ return -1;<br />
+ }<br />
+ reti = regexec(&regex, path, 2, matches, 0);<br />
+ int return_value = -1;<br />
+ if (!reti) {<br />
+ int match_size = matches[1].rm_eo - matches[1].rm_so;<br />
+ char *matchgroup = malloc(sizeof(char) * (1+match_size));<br />
+ matchgroup[match_size] = '\0';<br />
+ memcpy(matchgroup,&path[matches[1].rm_so],match_size);<br />
+ struct group *group_info = getgrnam(matchgroup);<br />
+ if (group_info == NULL) {<br />
+ return_value = -1;<br />
+ } else {<br />
+ return_value = group_info->gr_gid;<br />
+ }<br />
+<br />
+ free(matchgroup);<br />
+ }<br />
+ regfree(&regex);<br />
+ return return_value;<br />
+}<br />
+<br />
+<br />
/* FIXME: another thread may race to see the old owner before the chown is done.<br />
Is there a scenario where this compromises security? Or application correctness? */<br />
static void chown_new_file(const char *path, struct fuse_context *fc, int (*chown_func)(const char*, uid_t, gid_t))<br />
@@ -339,6 +379,14 @@ static void chown_new_file(const char *p<br />
if (settings.create_for_gid&nbsp;!= -1)<br />
file_group = settings.create_for_gid;<br />
<br />
+ //printf("Old file permission:&nbsp;%d&nbsp;%d\n",settings.use_permission_enforcement,file_group);<br />
+ if (settings.use_permission_enforcement) {<br />
+ <br />
+ int new_gid = get_gid(path);<br />
+ //printf("New file permssion:&nbsp;%d\n",new_gid);<br />
+ file_group = new_gid;<br />
+ }<br />
+<br />
if ((file_owner&nbsp;!= -1) || (file_group&nbsp;!= -1)) {<br />
if (chown_func(path, file_owner, file_group) == -1) {<br />
DPRINTF("Failed to chown new file or directory (%d)", errno);<br />
@@ -1670,6 +1718,13 @@ int main(int argc, char *argv[])<br />
bindfs_oper.listxattr = NULL;<br />
bindfs_oper.removexattr = NULL;<br />
}<br />
+ if (strcmp(settings.mntdest,"/home/iba") || <br />
+ strcmp(settings.mntdest,"/home/cies") ||<br />
+ strcmp(settings.mntdest,"/home/bestuur") ||<br />
+ strcmp(settings.mntdest,"/home/extern")) {<br />
+ settings.use_permission_enforcement = 1;<br />
+ }<br />
+ <br />
<br />
/* fuse_main will daemonize by fork()'ing. The signal handler will persist. */<br />
setup_signal_handling();<br />
</pre><br />
<br />
TODO: Locatie waar de code terug te vinden is. (Wat is een handige plek?)<br />
<br />
== Compilatie, debuggen, deployment ==<br />
De code bevat een Makefile, dus kan gewoon gecompileerd worden met de standaard ./configure en make. De binary is een executable met de naam "bindfs". Als deze neergezet wordt in een locatie in het systeempath zoals /usr/bin/ wordt deze automatisch herkend en gebruikt als je als vstype fuse.bindfs opgeeft met mount.<pre>mount -t fuse.bindfs</pre><br />
Voor compilatie zijn een standaard c compiler (zowel gcc als clang werkt) nodig en de package fuse-devel. Indien gecompileerd wordt op een CentOS 7 machine dan is deze executable niet te gebruiken op CentOS 6 vanwege een verouderde libc versie, andersom werkt wel. De executable kan ook eenvoudig gedebugd worden door een handmatige mount te doen met de -D optie.<pre>/usr/sbin/bindfs -d -o chmod-filter=g+rwD,create-with-perms=g+rwD,perms=g+rwD,chgrp-ignore,nonempty /mnt/home/ /home</pre><br />
<br />
[[Category:Sysop]]</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BindfsBindfs2015-06-03T12:04:06Z<p>Johand: Created page with "Op een aantal plekken op het A-Eskwadraat systeem wordt [http://bindfs.org/ BindFS] gebruikt om permissies van commissies e.d. goed te houden. Eerst werd dit gedaan door de ''..."</p>
<hr />
<div>Op een aantal plekken op het A-Eskwadraat systeem wordt [http://bindfs.org/ BindFS] gebruikt om permissies van commissies e.d. goed te houden. Eerst werd dit gedaan door de '''umask''' op ''0002'' te zetten, waardoor bestanden en directories altijd group writeable zijn. Dit gaat echter nog altijd fout in een aantal scenario's.<br />
<br />
<br />
<br />
*Sommige programma's zoals google-chrome downloaden bestanden altijd met rechten 640 als user:primary-group, ongeacht umask en of de directory de set group-id bit heeft. Bij het downloaden van bestanden direct naar een comissiemap gaat dit dan fout.<br />
*Een mv is in feite een rename en daarbij worden de rechten e.d. niet aangepast. Als iemand een file mv'ed van zijn homedir naar het commissieaccount heeft hij dus nog de oude rechten en kan de commissie er niet bij.<br />
*Bij een cp wordt er wel gekeken naar zaken als setgid bits, maar worden de rechten wel meegekopieerd, wat een probleem kan zijn als het origineel niet group-writeable is.<br />
<br />
De enige manier om bovenstaande problemen structureel op te lossen is om deze permissies hard op file system niveau af te dwingen. Hiervoor wordt [http://bindfs.org/ BindFS] gebruikt. Dit is een [http://fuse.sourceforge.net/ Fuse] file system waarmee een directory op een andere plek gemount kan worden, net zoals bij ''mount --bind'', maar waarbij de permissies ook nog aangepast kunnen worden. Om echter te zorgen dat de permissies van bestanden dynamisch aangepast worden afhankelijk van de locatie was het echter nodig om [http://bindfs.org/ BindFS] te patchen.<br />
<br />
== Gebruikte opties van BindFS ==<br />
<br />
Als we kijken naar de /etc/fstab van een systeem dat [http://bindfs.org/ BindFS] gebruikt zien we de volgende opties.<br />
<br />
*chmod-filter=g+rwD: Zorgt ervoor dat als er een chmod plaats vind op een file altijd de bits g+rw voor files en g+rwx voor directories geset worden. Een chmod 600 wordt dan bijvoorbeeld uitgevoerd als chmod 660 op de achtergrond.<br />
*create-with-perms=g+rwD: Permissies worden aangemaakt met g+rwD rechten.<br />
*perms=g+rwD: Bestaande bestanden worden gepresenteerd alsof ze g+rwD rechten hebben, ook al hoeft dat op de originele locatie niet zo te zijn.<br />
*chgrp-ignore: Negeer chgrp commando's. Dit is nodig omdat programma's als mv of google-chrome anders handmatig de group verkeerd zetten. Dit heeft wel als side effect dat handmatig rechten goedzetten dus ook niet meer kan.<br />
*nonempty: Zorgt ervoor dat [http://fuse.sourceforge.net/ Fuse] de directory in een niet lege directory kan mounten.<br />
*noauto: Eerst moeten de home directories in /mnt/home gemount worden, voordat [http://bindfs.org/ BindFS] deze weer in /home kan mounten. Dit wordt gedaan door het script /usr/local/sbin/mount-dirs dat via een service gerund wordt. Deze service start pas nadat netwerk-file systems gemount zijn.<br />
<br />
== Custom BindFS patch ==<br />
<br />
Met BindFS is het mogelijk om een enkele user en group te forcen, maar in ons geval willen we dit dynamisch doen, afhankelijk van de locatie van het bestand. Er is dus al code om een group-id te force'n, dus het enige wat gedaan moet worden is dit dynamisch te maken. Allereerst wordt bij het opstarten gekeken of de destination van de mount /home/iba, /home/cies, /home/bestuur of /home/extern is en alleen dan gebruiken we permission enforcement (settings.use_permission_enforcement). Er is gekozen om 4 aparte mountpoints te maken, zodat mv's nu cross-file systems zijn en dus geen rename meer zijn. Verder willen we ook geen permissies enforcen op de /home. Daarna wordt in de chown_new_file functie gekeken of de settings.use_permission_enforcement bit geset is en zoja, dan kijken we naar de directory van de file met behulp van een regex en zoeken we de bijbehorende group-id. Hierbij wordt als vuistregel gebruikt dat de naam van de top directory ook de group-name is. Dit levert problemen op als de naam van de homedir van een cie anders is dan de group-name.<br />
<pre>@@ -63,6 +63,8 @@<br />
#ifdef HAVE_SETXATTR<br />
#include <sys/xattr.h><br />
#endif<br />
+#include <linux/limits.h><br />
+#include <regex.h><br />
<br />
#include <fuse.h><br />
#include <fuse_opt.h><br />
@@ -141,6 +143,9 @@ static struct Settings {<br />
int ctime_from_mtime;<br />
int hide_hard_links;<br />
<br />
+ //Custom made for sysop<br />
+ int use_permission_enforcement;<br />
+<br />
} settings;<br />
<br />
<br />
@@ -306,6 +311,41 @@ static int getattr_common(const char *pr<br />
return 0;<br />
}<br />
<br />
+int get_gid(const char *path) {<br />
+<br />
+ regex_t regex;<br />
+ int reti;<br />
+<br />
+ regmatch_t matches[2];<br />
+<br />
+// reti = regcomp(&regex,"^/home/(cies|extern|iba|bestuur)/([^/]+)", REG_EXTENDED);<br />
+ reti = regcomp(&regex,"^([^/]+)", REG_EXTENDED);<br />
+ if (reti) {<br />
+ fprintf(stderr, "Could not compile regex\n");<br />
+ regfree(&regex);<br />
+ return -1;<br />
+ }<br />
+ reti = regexec(&regex, path, 2, matches, 0);<br />
+ int return_value = -1;<br />
+ if (!reti) {<br />
+ int match_size = matches[1].rm_eo - matches[1].rm_so;<br />
+ char *matchgroup = malloc(sizeof(char) * (1+match_size));<br />
+ matchgroup[match_size] = '\0';<br />
+ memcpy(matchgroup,&path[matches[1].rm_so],match_size);<br />
+ struct group *group_info = getgrnam(matchgroup);<br />
+ if (group_info == NULL) {<br />
+ return_value = -1;<br />
+ } else {<br />
+ return_value = group_info->gr_gid;<br />
+ }<br />
+<br />
+ free(matchgroup);<br />
+ }<br />
+ regfree(&regex);<br />
+ return return_value;<br />
+}<br />
+<br />
+<br />
/* FIXME: another thread may race to see the old owner before the chown is done.<br />
Is there a scenario where this compromises security? Or application correctness? */<br />
static void chown_new_file(const char *path, struct fuse_context *fc, int (*chown_func)(const char*, uid_t, gid_t))<br />
@@ -339,6 +379,14 @@ static void chown_new_file(const char *p<br />
if (settings.create_for_gid&nbsp;!= -1)<br />
file_group = settings.create_for_gid;<br />
<br />
+ //printf("Old file permission:&nbsp;%d&nbsp;%d\n",settings.use_permission_enforcement,file_group);<br />
+ if (settings.use_permission_enforcement) {<br />
+ <br />
+ int new_gid = get_gid(path);<br />
+ //printf("New file permssion:&nbsp;%d\n",new_gid);<br />
+ file_group = new_gid;<br />
+ }<br />
+<br />
if ((file_owner&nbsp;!= -1) || (file_group&nbsp;!= -1)) {<br />
if (chown_func(path, file_owner, file_group) == -1) {<br />
DPRINTF("Failed to chown new file or directory (%d)", errno);<br />
@@ -1670,6 +1718,13 @@ int main(int argc, char *argv[])<br />
bindfs_oper.listxattr = NULL;<br />
bindfs_oper.removexattr = NULL;<br />
}<br />
+ if (strcmp(settings.mntdest,"/home/iba") || <br />
+ strcmp(settings.mntdest,"/home/cies") ||<br />
+ strcmp(settings.mntdest,"/home/bestuur") ||<br />
+ strcmp(settings.mntdest,"/home/extern")) {<br />
+ settings.use_permission_enforcement = 1;<br />
+ }<br />
+ <br />
<br />
/* fuse_main will daemonize by fork()'ing. The signal handler will persist. */<br />
setup_signal_handling();<br />
</pre><br />
<br />
TODO: Locatie waar de code terug te vinden is. (Wat is een handige plek?)<br />
<br />
== Compilatie, debuggen, deployment ==<br />
De code bevat een Makefile, dus kan gewoon gecompileerd worden met de standaard ./configure en make. De binary is een executable met de naam "bindfs". Als deze neergezet wordt in een locatie in het systeempath zoals /usr/bin/ wordt deze automatisch herkend en gebruikt als je als vstype fuse.bindfs opgeeft met mount.<pre>mount -t fuse.bindfs</pre><br />
Voor compilatie zijn een standaard c compiler (zowel gcc als clang werkt) nodig en de package fuse-devel. Indien gecompileerd wordt op een CentOS 7 machine dan is deze executable niet te gebruiken op CentOS 6 vanwege een verouderde libc versie, andersom werkt wel. De executable kan ook eenvoudig gedebugd worden door een handmatige mount te doen met de -D optie.<pre>/usr/sbin/bindfs -d -o chmod-filter=g+rwD,create-with-perms=g+rwD,perms=g+rwD,chgrp-ignore,nonempty /mnt/home/ /home</pre></div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/ZFSZFS2015-02-09T21:30:30Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:ZFS}}<br />
[[category:sysop]]<br />
[http://en.wikipedia.org/wiki/ZFS ZFS] is het file system dat gebruikt wordt om alle actieve data in op te slaan op [[Haskell]]. Oorspronkelijk is het ontwikkeld door Sun Microsystems voor [http://en.wikipedia.org/wiki/Solaris_%28operating_system%29 Solaris]. Vervolgens is het geport naar onder andere [https://wiki.freebsd.org/ZFS FreeBSD] en [http://zfsonlinux.org/ Linux]. Omdat het ontwikkeld is onder de [http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License CDDL] license en daarom is [http://zfsonlinux.org/ ZFS on Linux] geen onderdeel van de kernel, maar een losse module die via dkms apart ingeladen moet worden. Op [[Haskell]] draait ZFS dus ook niet voor zijn root partitie, maar alleen voor data partities. Het zou anders kunnen dat bij een kernel of zfs update de kernel modules niet goed gebouwd worden je uberhaupt niet kan booten en dit is vrij problematisch.<br />
<br />
== Volume Manager vs File System ==<br />
ZFS is niet alleen een file system, het is ook een volume manager, zoals [http://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29 LVM]. Het is belangrijk om dit verschil tussen deze 2 lagen in het achterhoofd te houden. De bovenste laag heet bij ZFS de pool. De pool bestaat uit een aantal disks. Deze kunnen dan gemirrored worden, of in een willekeurige raid gezet worden. Deze pool werkt ongeveer hetzelfde als bij LVM. Er is een pool met data beschikbaar en deze kan vervolgens weer gesplitst worden in datasets. Elke dataset heeft een aantal properties. Veel opties die bij andere dingen als mount opties in de fstab staan zijn in ZFS properties (mountpoint/extended attributes/atime/compressie). Er is ook een ZFS service en die regelt bij het opstarten alles zelf met betrekking tot mounten en sharen van file systems, dus er is niets van zfs te zien in /etc/fstab.<br />
<br />
== Raid Configuratie ==<br />
ZFS draait in een zogehete raidz1. Dit is in feite een raid 5 met wat extra voordelen, vanwege de integratie. Raidz's hebben geen last van het zogehete [http://www.raid-recovery-guide.com/raid5-write-hole.aspx Write Hole] probleem.<br />
<br />
== Caching ==<br />
<br />
== Do's and Don't == <br />
<br />
=== Do's ===<br />
De man pages van de commando's zfs en zpool zijn zeer uitgebreid. In het geval dat je niet helemaal weet hoe iets werkt, kijk eerst in de man page.<br />
man zpool<br />
man zfs<br />
<br />
=== Dont's ===<br />
Doe nooit iets met zpool labelclear, dit doet enge dingen met je partities.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/ZFSZFS2015-02-03T16:22:38Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:ZFS}}<br />
[[category:sysop]]<br />
[http://en.wikipedia.org/wiki/ZFS ZFS] is het file system dat gebruikt wordt om alle actieve data in op te slaan op [[Haskell]]. Oorspronkelijk is het ontwikkeld door Sun Microsystems voor [http://en.wikipedia.org/wiki/Solaris_%28operating_system%29 Solaris]. Vervolgens is het geport naar onder andere [https://wiki.freebsd.org/ZFS FreeBSD] en [http://zfsonlinux.org/ Linux]. Omdat het ontwikkeld is onder de [http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License CDDL] license en daarom is [http://zfsonlinux.org/ ZFS on Linux] geen onderdeel van de kernel, maar een losse module die via dkms apart ingeladen moet worden. Op [[Haskell]] draait ZFS dus ook niet voor zijn root partitie, maar alleen voor data partities. Het zou anders kunnen dat bij een kernel of zfs update de kernel modules niet goed gebouwd worden je uberhaupt niet kan booten en dit is vrij problematisch.<br />
<br />
== Volume Manager vs File System ==<br />
ZFS is niet alleen een file system, het is ook een volume manager, zoals [http://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29 LVM]. Het is belangrijk om dit verschil tussen deze 2 lagen in het achterhoofd te houden. De bovenste laag heet bij ZFS de pool. De pool bestaat uit een aantal disks. Deze kunnen dan gemirrored worden, of in een willekeurige raid gezet worden. Deze pool werkt ongeveer hetzelfde als bij LVM. Er is een pool met data beschikbaar.<br />
<br />
== Raid Configuratie ==<br />
ZFS draait in een zogehete raidz1. Dit is in feite een raid 5 met wat extra voordelen, vanwege de integratie. Raidz's hebben geen last van het zogehete [http://www.raid-recovery-guide.com/raid5-write-hole.aspx Write Hole] probleem.<br />
<br />
== Caching ==<br />
<br />
== Do's and Don't == <br />
<br />
=== Do's ===<br />
De man pages van de commando's zfs en zpool zijn zeer uitgebreid. In het geval dat je niet helemaal weet hoe iets werkt, kijk eerst in de man page.<br />
man zpool<br />
man zfs<br />
<br />
=== Dont's ===<br />
Doe nooit iets met zpool labelclear, dit doet enge dingen met je partities.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/ZFSZFS2015-01-28T20:24:27Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:ZFS}}<br />
[[category:sysop]]<br />
[http://en.wikipedia.org/wiki/ZFS ZFS] is het file system dat gebruikt wordt om alle actieve data in op te slaan op [[Haskell]]. Oorspronkelijk is het ontwikkeld door Sun Microsystems voor [http://en.wikipedia.org/wiki/Solaris_%28operating_system%29 Solaris]. Vervolgens is het geport naar onder andere [https://wiki.freebsd.org/ZFS FreeBSD] en [http://zfsonlinux.org/ Linux]. Omdat het ontwikkeld is onder de [http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License CDDL] license en daarom is [http://zfsonlinux.org/ ZFS on Linux] geen onderdeel van de kernel, maar een losse module die via dkms apart ingeladen moet worden. Op [[Haskell]] draait ZFS dus ook niet voor zijn root partitie, maar alleen voor data partities. Het zou anders kunnen dat bij een kernel of zfs update de kernel modules niet goed gebouwd worden je uberhaupt niet kan booten en dit is vrij problematisch.<br />
<br />
== Volume Manager vs File System ==<br />
ZFS is niet alleen een file system, het is ook een volume manager, zoals [http://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29 LVM]. Het is belangrijk om dit verschil tussen deze 2 lagen in het achterhoofd te houden. De bovenste laag heet bij ZFS de pool. De pool bestaat uit een aantal disks. Deze kunnen dan gemirrored worden, of in een willekeurige raid gezet worden. Deze pool werkt ongeveer hetzelfde als bij LVM. Er is een pool met data beschikbaar.<br />
<br />
== Raid Configuratie ==<br />
ZFS draait in een zogehete raidz1. Dit is in feite een raid 5 met wat extra voordelen, vanwege de integratie. Raidz's hebben geen last van het zogehete [http://www.raid-recovery-guide.com/raid5-write-hole.aspx Write Hole] probleem.<br />
<br />
== Caching ==</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/ZFSZFS2015-01-28T20:21:50Z<p>Johand: </p>
<hr />
<div>{{DISPLAYTITLE:ZFS}}<br />
[[category:sysop]]<br />
[http://en.wikipedia.org/wiki/ZFS ZFS] is het file system dat gebruikt wordt om alle actieve data in op te slaan op [[Haskell]]. Oorspronkelijk is het ontwikkeld door Sun Microsystems voor [http://en.wikipedia.org/wiki/Solaris_%28operating_system%29 Solaris]. Vervolgens is het geport naar onder andere [https://wiki.freebsd.org/ZFS FreeBSD] en [http://zfsonlinux.org/ Linux]. Omdat het ontwikkeld is onder de [http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License CDDL] license en daarom is [http://zfsonlinux.org/ ZFS on Linux] geen onderdeel van de kernel, maar een losse module die via dkms apart ingeladen moet worden. Op [[Haskell]] draait ZFS dus ook niet voor zijn root partitie, maar alleen voor data partities. Het zou anders kunnen dat bij een kernel of zfs update de kernel modules niet goed gebouwd worden je uberhaupt niet kan booten en dit is vrij problematisch.<br />
<br />
== Volume Manager vs File System ==<br />
ZFS is niet alleen een file system, het is ook een volume manager, zoals [http://en.wikipedia.org/wiki/Logical_Volume_Manager_%28Linux%29 LVM]. Het is belangrijk om dit verschil tussen deze 2 lagen in het achterhoofd te houden. De bovenste laag heet bij ZFS de pool. De pool bestaat uit een aantal disks. Deze kunnen dan gemirrored worden, of in een willekeurige raid gezet worden.<br />
<br />
== Raid Configuratie ==<br />
ZFS draait in een zogehete raidz1. Dit is in feite een raid 5 met wat extra voordelen, vanwege de integratie. Raidz's hebben geen last van het zogehete [http://www.raid-recovery-guide.com/raid5-write-hole.aspx Write Hole] probleem.<br />
<br />
== Caching ==</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/ZFSZFS2015-01-28T19:49:50Z<p>Johand: Created page with "{{DISPLAYTITLE:ZFS}} category:sysop ZFS is het file system dat gebruikt wordt om alle actieve data in op te slaan op Haskell. Oorspronkelijk is het ontwikkeld door Sun..."</p>
<hr />
<div>{{DISPLAYTITLE:ZFS}}<br />
[[category:sysop]]<br />
ZFS is het file system dat gebruikt wordt om alle actieve data in op te slaan op [[Haskell]]. Oorspronkelijk is het ontwikkeld door Sun Microsystems voor [http://en.wikipedia.org/wiki/Solaris_%28operating_system%29 Solaris]. Vervolgens is het geport naar onder andere [https://wiki.freebsd.org/ZFS FreeBSD] en [http://zfsonlinux.org/ Linux]. Omdat het ontwikkeld is onder de [http://en.wikipedia.org/wiki/Common_Development_and_Distribution_License CDDL] license en daarom is [http://zfsonlinux.org/ ZFS on Linux] geen onderdeel van de kernel, maar een losse module die via dkms apart ingeladen moet worden. Op [[Haskell]] draait ZFS dus ook niet voor zijn root partitie, maar alleen voor data partities. Het zou anders kunnen dat bij een kernel of zfs update de kernel modules niet goed gebouwd worden je uberhaupt niet kan booten en dit is vrij problematisch.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/QuotaQuota2015-01-19T14:28:32Z<p>Johand: </p>
<hr />
<div>[[category:sysop]]<br />
Om het gebruik van schrijfruimte te beperken gebruiken we een quota systeem dat gebouwd is op de faciliteiten die zfs biedt als filesystem. Momenteel gebruiken we alleen userquota en geen groupquota. <br />
<br />
Als mensen direct bestanden kunnen aanpassen bij comissieaccounts worden zij wel owner van die files. Om dit probleem te vermijden zullen groupquota's gebruikt moeten gaan worden, maar dit zal een relatief kleine aanpassing zijn mits de permissies goed staan. De zfs dataset(s) waarop userquota gebruikt worden is storage/home. <br />
<br />
De quota worden opgeslagen in een sqlite3 file ''/home/quota.db''. Het is niet de bedoeling dat deze file direct gemanipuleerd wordt, maar er is een wrapper beschikbaar in de vorm van het script ''changequota'' Elke nacht wordt aan de hand van deze file met een cronjob de userquota ingesteld op de dataset(s). Mocht er accuut iets aangepast moeten worden, dan moet dit ook nog handmatig aangepast worden op haskell.<br />
<br />
In het hypotetische geval dat de ''spocie'' op hard quotum zit dan moeten er 2 dingen gedaan worden. Voer ''changequota'' uit als root:<br />
<br />
sudo changequota $user<br />
<br />
Toevoegen Quotum<br />
# Bij het toevoegen van quota vul hier de hoeveelheid extra quota in (bv. 42MB, 1.5G, etc).<br />
# Het is ook mogelijk om een tijdslimiet hierop te zetten (bv. serious quotum), doe dit preferabel in een formaat als ''dd-mm-yyyy''.<br />
# Vul de reden in waarom de gebruiker meer quotum behoeft<br />
<br />
Verwijderen Quotum<br />
# Bij het verwijderen van quota wordt er een lijst getoond van entries in de database en hoeveel extra quotum deze entry de gebruiker geeft. Deze lijst is 0 indexed. Standaard heeft elke gebruiker/comissie 1Gb quotum. <br />
# Vul hier het getal in van de entry die je wilt verwijderen. Zou je dus je standaard quotum willen verwijderen dan vul je hier 0 in.<br />
<br />
ZFS werkt met hard quotum. Het harde quotum is standaard quotum +10GB. Wanneer de grace periode van 2 weken over is wordt het quotum op 1 bit gezet.<br />
Standaard quota worden elke nacht gegenereerd en in de database gezet, mocht deze per ongeluk verwijderd worden dan is het handiger om deze automatisch te laten genereren in plaats van dit weer handmatig te fixen.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/SvnSvn2014-11-07T15:57:40Z<p>Johand: </p>
<hr />
<div>[[category:sysop]]<br />
[[category:software]]<br />
Op de vm-gitsvn staan alle svn-repos zoals bijv de Sysop-svn.<br />
<br />
== Svn en websvn installeren ==<br />
=== IPA/Kerberos ===<br />
Installeer svn, websvn en de bijbehorende modules om het goed met kerberos te laten werken:<br />
<pre><br />
yum install subversion websvn mod_auth_kerb mod_dav_svn<br />
</pre><br />
Zorg ervoor dat het bestand /etc/httpd/conf.d/websvn.conf er als volgt uit ziet:<br />
<pre><br />
Alias /websvn /usr/share/websvn/<br />
<br />
<Directory /usr/share/websvn/><br />
Options MultiViews Indexes FollowSymLinks Includes ExecCGI<br />
DirectoryIndex wsvn.php<br />
AuthType Kerberos<br />
AuthName "Kerberos Login"<br />
KrbMethodNegotiate On<br />
KrbMethodK5Passwd On<br />
KrbAuthRealms A-ESKWADRAAT.NL<br />
Krb5KeyTab /etc/httpd/krb5.keytab<br />
Require valid-user<br />
</Directory><br />
</pre><br />
en restart de httpd:<br />
<pre><br />
service httpd restart<br />
</pre><br />
Zorg er nu voor dat je svn-server met kerberos-credentials kan gebruiken. Maak in de ipaserver de service HTTP/"svnserver" aan. Voer dan op de svnserver het volgende uit:<br />
<pre><br />
ipa-getkeytab -s <ipa-server> -p HTTP/<svnserver> -k /etc/httpd/krb5.keytab<br />
chown apache:apache /etc/httpd/krb5.keytab<br />
</pre><br />
Maak de map /var/lib/svn aan en zet de selinux-context goed:<br />
<pre><br />
mkdir /var/lib/svn<br />
restorecon -Rvv /var/lib/svn<br />
</pre><br />
=== LDAP ===<br />
Installeer svn, websvn en de bijbehorende modules om het goed met kerberos te laten werken:<br />
<pre><br />
yum install subversion websvn mod_authz_ldap<br />
</pre><br />
Zorg ervoor dat het bestand /etc/httpd/conf.d/websvn.conf er als volgt uit ziet:<br />
<pre><br />
Alias /websvn /usr/share/websvn/<br />
<br />
<Directory /usr/share/websvn/><br />
Options MultiViews Indexes FollowSymLinks Includes ExecCGI<br />
DirectoryIndex wsvn.php<br />
AuthType Basic<br />
AuthBasicProvider ldap<br />
AuthLDAPURL ldap://ldap/ou=mensjes,ou=accounts,dc=a-eskwadraat,dc=nl?uid<br />
AuthName 'WebSVN'<br />
Require valid-user<br />
</Directory><br />
</pre><br />
en restart de httpd:<br />
<pre><br />
service httpd restart<br />
</pre><br />
Maak de map /var/lib/svn aan en zet de selinux-context goed:<br />
<pre><br />
mkdir /var/lib/svn<br />
restorecon -Rvv /var/lib/svn<br />
</pre><br />
<br />
== Nieuwe repo toevoegen ==<br />
Om een repo toe te voegen voeg je aan het bestand /etc/httpd/conf.d/subversion.conf het volgende toe:<br />
<pre><br />
<Location /websvn/wsvn/*reponaam*><br />
Require user user1@AESKWADRAAT user2@AESKWADRAAT ...<br />
</Location><br />
</pre><br />
en voeg je aan /etc/httpd/conf.d/subversion.conf toe<br />
<pre><br />
<Location /svn/*reponaam*><br />
DAV svn<br />
SVNPath /var/lib/svn/*reponaam*<br />
Options MultiViews Indexes FollowSymLinks Includes ExecCGI<br />
AuthType Kerberos<br />
AuthName "Kerberos Login"<br />
KrbMethodNegotiate On<br />
KrbMethodK5Passwd On<br />
KrbAuthRealms AESKWADRAAT<br />
Krb5KeyTab /etc/httpd/krb5.keytab<br />
Require user user1@AESKWADRAAT ...<br />
</Location><br />
</pre><br />
en voor ldap<br />
<pre><br />
<Location /svn/*reponaam*><br />
DAV svn<br />
SVNPath /var/lib/svn/*reponaam*<br />
Options MultiViews Indexes FollowSymLinks Includes ExecCGI<br />
AuthType Basic<br />
AuthBasicProvider ldap<br />
AuthLDAPURL ldap://ldap/ou=mensjes,ou=accounts,dc=a-eskwadraat,dc=nl?uid<br />
AuthName 'WebSVN'<br />
Require ldap-group cn=...<br />
</Location><br />
</pre><br />
en reload httpd<br />
<pre><br />
service httpd reload<br />
</pre><br />
Maak nu de nieuwe repo aan:<br />
<pre><br />
cd /var/lib/svn<br />
svnadmin create *repodir*<br />
</pre><br />
Zet ook de user en de groep van de repo goed.<br />
<br />
Zorg er nu voor dat de repo in het websvn overzicht staat. Voeg hiervoor toe aan /etc/websvn/config.php de volgende regel:<br />
<pre><br />
$config->addRepository("reponaam", "file:///var/lib/svn/repodir");<br />
</pre><br />
<br />
== SVN Checkout maken ==<br />
Om nu een checkout van een repository *reponaam* te maken voer je het volgende uit:<br />
<pre><br />
svn co http://*svnserver*/svn/*reponaam*<br />
</pre></div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/QuotaQuota2014-08-11T11:46:49Z<p>Johand: </p>
<hr />
<div>[[category:sysop]]<br />
Om het gebruik van schrijfruimte te beperken gebruiken we het quota systeem bovenop de faciliteiten gebouwd die zfs bied als filesystem. We gebruiken alleen userquota en geen groupquota, al kan dit in de toekomst misschien nog veranderen, aangezien dit problemen kan geven in de toekomst. Als mensen direct bestanden kunnen aanpassen bij comissieaccounts worden zij wel owner van die files. Om dit probleem te vermijden zullen groupquota's gebruikt moeten gaan worden, maar dit zal een relatief kleine aanpassing zijn mits de permissies goed staan. De zfs dataset(s) waarop userquota gebruikt worden is storage/home. <br />
<br />
De quota worden opgeslagen in een sqlite3 file ''/home/quota.db''. Het is niet de bedoeling dat deze file direct gemanipuleerd wordt, maar er is een wrapperdje beschikbaar in de vorm van het script ''changequota'' Elke nacht wordt aan de hand van deze file met een cronjob de bijbehorende userquota ingesteld op de dataset(s). Mocht er accuut iets aangepast moeten worden, dan moet dit ook nog handmatig aangepast worden op haskell.<br />
<br />
In het hypotetische geval dat de ''spocie'' op hard quotum zit dan moeten er 2 dingen gedaan worden. Voer ''changequota'' uit als root/sysop gebruiker.<br />
<br />
<pre>s sysop</pre><br />
<pre>changequota <user></pre><br />
<br />
Indien geen gebruiker opgegeven dan zal nog gevraagd worden deze in te voeren.<br />
Toevoegen Quotum<br />
# Bij het toevoegen van quota vul hier de hoeveelheid extra quota in (bv. 42MB, 1.5G, etc).<br />
# Het is ook mogelijk om een tijdslimiet hierop te zetten (bv. serious quotum), doe dit preferabel in een formaat als ''dd-mm-yyyy''.<br />
# Vul de reden in waarom de gebruiker meer quotum behoeft<br />
<br />
Verwijderen Quotum<br />
# Bij het verwijderen van quota wordt er een lijst getoond van entries in de database en hoeveel extra quotum deze entry de gebruiker geeft. Deze lijst is 0 indexed. Standaard heeft elke gebruiker/comissie 1Gb quotum. <br />
# Vul hier het getal in van de entry die je wilt verwijderen. Zou je dus je standaard quotum willen verwijderen dan vul je hier 0 in.<br />
<br />
ZFS werkt met hard quotum. Het harde quotum is standaard quotum +1GB. Wanneer de grace periode van 2 weken over is wordt het quotum op 1 bit gezet.<br />
Standaard quota worden elke nacht gegenereerd en in de database gezet, mocht deze per ongeluk verwijdert worden dan is het handiger om deze automatisch te laten genereren in plaats van dit weer handmatig te fixen.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T19:57:00Z<p>Johand: /* Versies */</p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
Uitgebreide informatie van Bacula zelf kan gevonden worden op [http://www.bacula.org/en/?page=documentation].<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
* Console. Dit is een simpel programmaatje die verbinding maakt met de Director en op die manier dingen kan doen als bestanden terugzetten en dergelijke.<br />
<br />
=== Configuratie Bestanden ===<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
=== Versies === <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.<br />
<br />
== Bestanden terug zetten ==<br />
<br />
Bestanden kunnen teruggezet worden door eerst de console te openen met het commmando bconsole op een machine waar dit geinstaleerd is. Een uitgebreide documentatie hierover is te vinden op [http://www.bacula.org/en/dev-manual/main/main/Restore_Command.html]<br />
<br />
$ bconsole<br />
<br />
Dit start de Console op van Bacula. Om een bestand te restoren typ restore<br />
<br />
*restore<br />
<br />
Hier kan je op verschillende manieren de backups selecteren die je wilt restoren. Houd hierbij rekening dat je alleen data uit een backup kan terugzetten die hij gebackupt heeft. Het is wel mogelijk om meerdere backups tegelijk te selecteren, om data over verschillende backups terug te zetten.<br />
<br />
Nadat je de backups hebt geselecteerd waarin de data staat die je wilt terugzetten maakt bacula een index van alle files die gebackupt zijn in de geselecteerde backups. In de shell waarin je terecht komt kan je gewoon simpele commando's als ls en cd gebruiken om te navigeren. Standaard worden geen files teruggezet en je kan zelf bestanden toevoegen die teruggezet moeten worden.<br />
<br />
* mark <wildcard><br />
<br />
* mark *<br />
<br />
zal bijvoorbeeld alle files terugzetten in de directory waar je je dan in bevind. Bestanden deselecteren kan met het unmark.<br />
<br />
Als alle gewenste files geselecteerd zijn kan je aangeven dat je klaar bent met done.<br />
<br />
* done<br />
<br />
Nu kan je selecteren naar welke File Daemon de backup gerestored moet worden.<br />
<br />
Aan het einde komt een overzicht te staan van alle opties en kan je nog dingen aanpassen zoals het filepath waar de backup naar toe gerestored moet worden. Zet hier / neer als je de files op hun originele plek terug wilt hebben. Standaard is dit /tmp/bacula-restore.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T19:56:35Z<p>Johand: /* Bestanden terug zetten */</p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
Uitgebreide informatie van Bacula zelf kan gevonden worden op [http://www.bacula.org/en/?page=documentation].<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
* Console. Dit is een simpel programmaatje die verbinding maakt met de Director en op die manier dingen kan doen als bestanden terugzetten en dergelijke.<br />
<br />
=== Configuratie Bestanden ===<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
== Versies == <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.<br />
<br />
== Bestanden terug zetten ==<br />
<br />
Bestanden kunnen teruggezet worden door eerst de console te openen met het commmando bconsole op een machine waar dit geinstaleerd is. Een uitgebreide documentatie hierover is te vinden op [http://www.bacula.org/en/dev-manual/main/main/Restore_Command.html]<br />
<br />
$ bconsole<br />
<br />
Dit start de Console op van Bacula. Om een bestand te restoren typ restore<br />
<br />
*restore<br />
<br />
Hier kan je op verschillende manieren de backups selecteren die je wilt restoren. Houd hierbij rekening dat je alleen data uit een backup kan terugzetten die hij gebackupt heeft. Het is wel mogelijk om meerdere backups tegelijk te selecteren, om data over verschillende backups terug te zetten.<br />
<br />
Nadat je de backups hebt geselecteerd waarin de data staat die je wilt terugzetten maakt bacula een index van alle files die gebackupt zijn in de geselecteerde backups. In de shell waarin je terecht komt kan je gewoon simpele commando's als ls en cd gebruiken om te navigeren. Standaard worden geen files teruggezet en je kan zelf bestanden toevoegen die teruggezet moeten worden.<br />
<br />
* mark <wildcard><br />
<br />
* mark *<br />
<br />
zal bijvoorbeeld alle files terugzetten in de directory waar je je dan in bevind. Bestanden deselecteren kan met het unmark.<br />
<br />
Als alle gewenste files geselecteerd zijn kan je aangeven dat je klaar bent met done.<br />
<br />
* done<br />
<br />
Nu kan je selecteren naar welke File Daemon de backup gerestored moet worden.<br />
<br />
Aan het einde komt een overzicht te staan van alle opties en kan je nog dingen aanpassen zoals het filepath waar de backup naar toe gerestored moet worden. Zet hier / neer als je de files op hun originele plek terug wilt hebben. Standaard is dit /tmp/bacula-restore.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T19:36:20Z<p>Johand: /* Bestanden terug zetten */</p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
Uitgebreide informatie van Bacula zelf kan gevonden worden op [http://www.bacula.org/en/?page=documentation].<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
* Console. Dit is een simpel programmaatje die verbinding maakt met de Director en op die manier dingen kan doen als bestanden terugzetten en dergelijke.<br />
<br />
=== Configuratie Bestanden ===<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
== Versies == <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.<br />
<br />
== Bestanden terug zetten ==<br />
<br />
Bestanden kunnen teruggezet worden door de Console te openen met het commmando <br />
<br />
$ bconsole</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T19:35:29Z<p>Johand: /* Bestanden terug zetten */</p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
Uitgebreide informatie van Bacula zelf kan gevonden worden op [http://www.bacula.org/en/?page=documentation].<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
* Console. Dit is een simpel programmaatje die verbinding maakt met de Director en op die manier dingen kan doen als bestanden terugzetten en dergelijke.<br />
<br />
=== Configuratie Bestanden ===<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
== Versies == <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.<br />
<br />
== Bestanden terug zetten ==<br />
<br />
Bestanden kunnen teruggezet worden door de Console te openen met het commmando <br />
<br />
$ bconsole</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T19:05:26Z<p>Johand: </p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
Uitgebreide informatie van Bacula zelf kan gevonden worden op [http://www.bacula.org/en/?page=documentation].<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
* Console. Dit is een simpel programmaatje die verbinding maakt met de Director en op die manier dingen kan doen als bestanden terugzetten en dergelijke.<br />
<br />
=== Configuratie Bestanden ===<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
== Versies == <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.<br />
<br />
== Bestanden terug zetten ==</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T18:54:32Z<p>Johand: </p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
Uitgebreide informatie van Bacula zelf kan gevonden worden op [http://www.bacula.org/en/?page=documentation].<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
<br />
=== Configuratie Bestanden ===<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
== Versies == <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BackupBackup2013-06-19T18:51:35Z<p>Johand: /* Nieuwe Systeem */</p>
<hr />
<div>[[category:sysop]]<br />
Elke dag worden er '''backups''' gemaakt van een groot deel van het systeem. Onder andere de homedirectories, de mail en de webpages worden gebackupt. [[Scratch]] wordt niet gebackupt.<br />
<br />
== Interne backups ==<br />
De interne backups zijn bedoeld om bestanden terug te kunnen halen die per ongeluk verwijderd zijn. De backups staan onder `/backup` in subdirectories met als naam de datum en tijd van de backup. Op den duur worden oude backups automatisch verwijderd, maar normaal kun je hier data terugvinden van 1 dag tot ongeveer een maand geleden. De subdirectory latest verwijst altijd naar de laatste backup (normaal van de afgelopen nacht).<br />
<br />
Binnen een backup directory staan de bestanden op exact dezelfde plaats en met dezelfde permissies als in het gewone bestandssysteem, dus om bijvoorbeeld het bestand `bla.txt` op het Sysopaccount terug te zetten, zou je het volgende commando gebruiken:<br />
<br />
$ cp /backup/latest/home/iba/sysop/bla.txt ~sysop<br />
<br />
== Externe backups ==<br />
Iedere nacht wordt er ook een off-site snapshot gemaakt naar [[claude]].<br />
<br />
== Manier van backuppen ==<br />
<br />
De backup scripts zitten in de [[Sysop scripts|Sysop SVN]]. Een korte uitleg per bestand:<br />
<br />
* `bu-mksnapshot`: maakt met behulp van `rsync` een snapshot naar `/backup`. Door het gebruik van een hardlink copy is de benodigde diskruimte zeer beperkt (een overhead van 100 tot 200 MB voor directorystructuur, plus alle gewijzigde files).<br />
* `bu-rmsnapshots`: ruimt een aantal snapshots op om te voorkomen dat `/backup` vol raakt.<br />
* `bu-extern`: externe backup door claude.a-eskwadraat.nl. Typ 'bu-extern' voor built-in help inclusief setupinformatie. Op claude staat een kopie van dit script.<br />
<br />
== Nieuwe Systeem ==<br />
<br />
In het nieuwe systeem worden backups gemaakt met behulp van [[Bacula]]. Op dit moment worden twee dingen gebackupt.<br />
* Alle snapshots die Proxmox maakt worden gebackupt.<br />
* De /home van de MailNFS vm wordt apart gebackupt.<br />
<br />
=== Virtual Machine Backup Schema ===<br />
Van de virtual machine's ziet het backup schema er als volgt uit:SpaceWalk, IPA, GitSVN en WWW ziet het backup schema er<br />
* Van de vm's SpaceWalk, IPA, GitSVN en WWW wordt maandag t/m zaterdag een dagelijkse backup gemaakt.<br />
* Elke zondag, behalve op 1ste zondagen, wordt een wekelijkse backup gemaakt voor alle vm's<br />
* Elke 1ste zondag van de maand wordt een maandelijkse backup gemaakt van alle vm's<br />
<br />
=== MailNFS Backup Schema ===<br />
Van de /home van MailnFS ziet het backup schema er als volgt uit:<br />
* Elke maandag t/m zaterdag wordt dagelijks een incrementele backup gemaakt.<br />
* Elke zondag, behalve op 1ste zondagen, wordt een wekelijkse differentiele backup gemaakt.<br />
* Elke 1ste zondag van de maand wordt een maandelijkse volledige backup gemaakt.<br />
<br />
=== Soorten Backups ===<br />
Er wordt gebruik gemaakt van 3 verschillende soorten backups.<br />
* Incrementele backups zijn backups die alleen veranderingen tot de vorige backup (ongeacht het soort)<br />
* Differentiele backups zijn backups die alle veranderingen tot de vorige full backup opslaan.<br />
* Full backups zijn backups die alles opslaan.<br />
<br />
=== Retention ===<br />
Backups worden niet voor eeuwig bewaard.<br />
* Dagelijkse backups worden na een week verwijdert.<br />
* Wekelijkse backups worden na een maand verwijdert.<br />
* Maandelijkse backups worden na 3 maanden verwijdert.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BackupBackup2013-06-19T18:50:03Z<p>Johand: </p>
<hr />
<div>[[category:sysop]]<br />
Elke dag worden er '''backups''' gemaakt van een groot deel van het systeem. Onder andere de homedirectories, de mail en de webpages worden gebackupt. [[Scratch]] wordt niet gebackupt.<br />
<br />
== Interne backups ==<br />
De interne backups zijn bedoeld om bestanden terug te kunnen halen die per ongeluk verwijderd zijn. De backups staan onder `/backup` in subdirectories met als naam de datum en tijd van de backup. Op den duur worden oude backups automatisch verwijderd, maar normaal kun je hier data terugvinden van 1 dag tot ongeveer een maand geleden. De subdirectory latest verwijst altijd naar de laatste backup (normaal van de afgelopen nacht).<br />
<br />
Binnen een backup directory staan de bestanden op exact dezelfde plaats en met dezelfde permissies als in het gewone bestandssysteem, dus om bijvoorbeeld het bestand `bla.txt` op het Sysopaccount terug te zetten, zou je het volgende commando gebruiken:<br />
<br />
$ cp /backup/latest/home/iba/sysop/bla.txt ~sysop<br />
<br />
== Externe backups ==<br />
Iedere nacht wordt er ook een off-site snapshot gemaakt naar [[claude]].<br />
<br />
== Manier van backuppen ==<br />
<br />
De backup scripts zitten in de [[Sysop scripts|Sysop SVN]]. Een korte uitleg per bestand:<br />
<br />
* `bu-mksnapshot`: maakt met behulp van `rsync` een snapshot naar `/backup`. Door het gebruik van een hardlink copy is de benodigde diskruimte zeer beperkt (een overhead van 100 tot 200 MB voor directorystructuur, plus alle gewijzigde files).<br />
* `bu-rmsnapshots`: ruimt een aantal snapshots op om te voorkomen dat `/backup` vol raakt.<br />
* `bu-extern`: externe backup door claude.a-eskwadraat.nl. Typ 'bu-extern' voor built-in help inclusief setupinformatie. Op claude staat een kopie van dit script.<br />
<br />
== Nieuwe Systeem ==<br />
<br />
In het nieuwe systeem worden backups gemaakt met behulp van [Bacula]. Op dit moment worden twee dingen gebackupt.<br />
* Alle snapshots die Proxmox maakt worden gebackupt.<br />
* De /home van de MailNFS vm wordt apart gebackupt.<br />
<br />
=== Virtual Machine Backup Schema ===<br />
Van de virtual machine's ziet het backup schema er als volgt uit:SpaceWalk, IPA, GitSVN en WWW ziet het backup schema er<br />
* Van de vm's SpaceWalk, IPA, GitSVN en WWW wordt maandag t/m zaterdag een dagelijkse backup gemaakt.<br />
* Elke zondag, behalve op 1ste zondagen, wordt een wekelijkse backup gemaakt voor alle vm's<br />
* Elke 1ste zondag van de maand wordt een maandelijkse backup gemaakt van alle vm's<br />
<br />
=== MailNFS Backup Schema ===<br />
Van de /home van MailnFS ziet het backup schema er als volgt uit:<br />
* Elke maandag t/m zaterdag wordt dagelijks een incrementele backup gemaakt.<br />
* Elke zondag, behalve op 1ste zondagen, wordt een wekelijkse differentiele backup gemaakt.<br />
* Elke 1ste zondag van de maand wordt een maandelijkse volledige backup gemaakt.<br />
<br />
=== Soorten Backups ===<br />
Er wordt gebruik gemaakt van 3 verschillende soorten backups.<br />
* Incrementele backups zijn backups die alleen veranderingen tot de vorige backup (ongeacht het soort)<br />
* Differentiele backups zijn backups die alle veranderingen tot de vorige full backup opslaan.<br />
* Full backups zijn backups die alles opslaan.<br />
<br />
=== Retention ===<br />
Backups worden niet voor eeuwig bewaard.<br />
* Dagelijkse backups worden na een week verwijdert.<br />
* Wekelijkse backups worden na een maand verwijdert.<br />
* Maandelijkse backups worden na 3 maanden verwijdert.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T18:23:30Z<p>Johand: </p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
Uitgebreide informatie van Bacula zelf kan gevonden worden op [http://www.bacula.org/en/?page=documentation].<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
<br />
== Configuratie Bestanden ==<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
== Versies == <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/HaskellHaskell2013-06-19T18:22:10Z<p>Johand: /* Extra geïnstalleerd */</p>
<hr />
<div>{{DISPLAYTITLE:Haskell}}<br />
[[category:hardware]]<br />
[[category:sysop]]<br />
'''Haskell''' is een server die gekocht is voor gebruik bij het [http://2012.bapc.eu BAPC 2012]. De machine is inmiddels overgedragen aan A–Eskwadraat en zal op termijn [[max]] vervangen. Hij is vernoemd naar de Amerikaanse wiskundige en logicus [http://nl.wikipedia.org/wiki/Haskell_Curry Haskell Brooks Curry].<br />
<br />
== Hardware ==<br />
Haskell is in tegenstelling tot [[max]] een zelf samengestelde computer, maar wel met serverwaardige onderdelen. Te noemen:<br />
* 1x Chieftec UNI BX-02B-B-B Zwart (behuizing)<br />
* 1x Zalman ZM660-XT (voeding)<br />
* 1x Intel Server Board S2600CP4 (moederbord)<br />
* 1x Intel Xeon E5-2620 (processor)<br />
* 1x Intel Thermal Solution RTS2011LC (processor waterkoeling)<br />
* 4x Kingston ValueRAM 8G (ram)<br />
* 4x Seagate Barracuda 7200 2TB (hardeschijven)<br />
<br />
== Software ==<br />
Haskell draait [http://www.proxmox.com/proxmox-ve Proxmox VE], een debian-distributie gericht op virtualisatie.<br />
Deze server hangt dan ook niet in spacewalk of andere systemen.<br />
<br />
Om de virtuele omgevingen te beheren kan alleen ingelogd worden als root op [http://haskell:8006/ de site].<br />
<br />
=== Extra geïnstalleerd ===<br />
[[dnsmasq]]<br />
[[Bacula]] File Daemon<br />
<br />
=== APT ===<br />
Debian gebruikt apt als package manager.<br />
Beheer van de package op haskell valt niet zoals de andere systemen onder spacewalk.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T18:07:52Z<p>Johand: /* Configuratie files */</p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
<br />
== Configuratie Bestanden ==<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
== Versies == <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T18:07:40Z<p>Johand: </p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
<br />
== Configuratie files ==<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.<br />
<br />
== Versies == <br />
Omdat op verschillende plekken Bacula geinstaleerd wordt zijn er op dit moment 2 versies die gebruikt worden en (nog) zonder problemen met elkaar praten. Op machines waar CentOS 6.4 draait is versie 5.0.0 geinstaleerd.<br />
Op Haskell draait Proxmox waar een nieuwere versie van Bacula in de repositories staat, dus hier is versie 5.2.6 geinstaleerd.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/BaculaBacula2013-06-19T17:55:30Z<p>Johand: Created page with "category:sysop Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma. == Onderdelen == Bac…"</p>
<hr />
<div>[[category:sysop]]<br />
<br />
Om backups te maken in het nieuwe systeem wordt gebruik gemaakt van Bacula. Dit is een open source, netwerk gebaseerd backup proggramma.<br />
<br />
== Onderdelen ==<br />
Bacula bestaat uit een aantal onderdelen die op verschillende plekken op een netwerk kunnen draaien.<br />
<br />
* Director. De Director is degene die bijhoudt waar alle andere onderdelen zich bevinden en coordineert en dirigeert '''alle''' andere onderdelen. De Director gaat draaien op Claude.<br />
* Storage Daemon. De Storage Daemon draait op de machine waar alle backups fysiek opgeslagen worden. De Storage Daemon praat met de database voor het opslaan van metadata en de File Daemons zodat deze direct hun data kunnen sturen naar de plek waar het opgeslagen wordt. De Storage Daemon gaat draaien op Claude.<br />
* Database. Alle metadata over de backups wordt opgeslagen in een MySQL database. Deze hoeft alleen te praten met de Director en de Storage daemon. Omdat deze beide al op Claude draaien en de database zelf ook op Claude draait is deze niet open gesteld naar buiten toe.<br />
* File Daemon. Dit zijn de clients die gebackupt worden. Op dit moment draaien deze op haskell zelf en in de MailNFS VM.<br />
<br />
== Configuratie files ==<br />
De configuratiebestanden van elk apart onderdeel is te vinden in de map /etc/bacula op de machine waar deze geinstaleerd is. Voor de Director, Storage Daemon en File Daemon heten deze bestanden respectievelijk bacula-dir.conf, bacula-sd.conf en bacula-fd.conf. Het gros van de configuratie, zoals wat gebackupt wordt en waar naartoe wordt gedaan in de Director.</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/SysopSysop2013-05-08T15:44:15Z<p>Johand: </p>
<hr />
<div>{{Commissie<br />
| naam = Sysop<br />
| plaatje = <br />
| type = commissie<br />
| jaren_actief = 1997-heden<br />
| email = sysop[dingetje]a-eskwadraat.nl<br />
| website = http://a-eskwadraat.nl/sysop<br />
| voorzitter = Lennaert Bel<br />
| leden = Rob Franken<br />Rob van de Werken<br />Lennaert Bel<br />Leon Oostrum<br />Gordian Zomer<br />Pepijn Overbeeke<br />Marten Spoor<br />Jitse Klomp<br />Johan Dorland<br />
}}<br />
'''Sysop''' is de A–Eskwadraatcommissie die verantwoordelijk is voor het beheer van het [[computerpark]] en alle andere [[:category:hardware|hardware]]. Sysop valt onder [[IBA]]. Ze zijn te bereiken op [mailto:sysop@A-Eskwadraat.nl].<br />
<br />
De Sysophandleidingen staan in de categorie [[:category:sysop|Sysop]]. De documentatie van scripts staat in de categorie [[:category:sysop scripts|Scripts]].<br />
<br />
== Leden ==<br />
In willekeurige volgorde van chronologie:<br />
<br />
* DrBob<br />
* RobRob<br />
* Lennaert (voorzitter)<br />
* Leon<br />
* Gordian<br />
* Pepijn<br />
* Marten<br />
* Jitse<br />
* Johan<br />
<br />
=== Gedeactiveerde leden ===<br />
Leden van Sysop zijn leden van IBA, zodoende kunnen ze niet lid-af worden. Dit is de lijst van gedeactiveerde leden:<br />
<br />
* Lars<br />
* Waltmeister<br />
* Loekie<br />
* A4z<br />
* Scotty<br />
* Steven<br />
* Sjeik<br />
* Stukjes Peer<br />
* Bash<br />
* Yoerin<br />
* Ctrlsoft<br />
* Neus<br />
* Kurk<br />
* (CPU) Killer<br />
* Lachebekje<br />
* Jef<br />
* SysV<br />
* Tobin<br />
* Baz<br />
* Ronalz<br />
* Baard<br />
* Frnk<br />
* Pretzel<br />
* Helga</div>Johandhttps://mediawiki.a-eskwadraat.nl/wiki/index.php/SysopSysop2013-05-08T15:40:09Z<p>Johand: </p>
<hr />
<div>{{Commissie<br />
| naam = Sysop<br />
| plaatje = <br />
| type = commissie<br />
| jaren_actief = 1997-heden<br />
| email = sysop[dingetje]a-eskwadraat.nl<br />
| website = http://a-eskwadraat.nl/sysop<br />
| voorzitter = Lennaert Bel<br />
| leden = Rob Franken<br />Rob van de Werken<br />Lennaert Bel<br />Leon Oostrum<br />Gordian Zomer<br />Pepijn Overbeeke<br />Marten Spoor<br />Jitse Klomp<br />
}}<br />
'''Sysop''' is de A–Eskwadraatcommissie die verantwoordelijk is voor het beheer van het [[computerpark]] en alle andere [[:category:hardware|hardware]]. Sysop valt onder [[IBA]]. Ze zijn te bereiken op [mailto:sysop@A-Eskwadraat.nl].<br />
<br />
De Sysophandleidingen staan in de categorie [[:category:sysop|Sysop]]. De documentatie van scripts staat in de categorie [[:category:sysop scripts|Scripts]].<br />
<br />
== Leden ==<br />
In willekeurige volgorde van chronologie:<br />
<br />
* DrBob<br />
* RobRob<br />
* Lennaert (voorzitter)<br />
* Leon<br />
* Gordian<br />
* Pepijn<br />
* Marten<br />
* Jitse<br />
* Johan<br />
<br />
=== Gedeactiveerde leden ===<br />
Leden van Sysop zijn leden van IBA, zodoende kunnen ze niet lid-af worden. Dit is de lijst van gedeactiveerde leden:<br />
<br />
* Lars<br />
* Waltmeister<br />
* Loekie<br />
* A4z<br />
* Scotty<br />
* Steven<br />
* Sjeik<br />
* Stukjes Peer<br />
* Bash<br />
* Yoerin<br />
* Ctrlsoft<br />
* Neus<br />
* Kurk<br />
* (CPU) Killer<br />
* Lachebekje<br />
* Jef<br />
* SysV<br />
* Tobin<br />
* Baz<br />
* Ronalz<br />
* Baard<br />
* Frnk<br />
* Pretzel<br />
* Helga</div>Johand