Benötige die default Werte aus der Rubrik default in der login.conf

R

ralli

Guest
Habe mich beim Ändern in der login.conf vertan und aus Versehen die Werte in der Klasse :\default geändert statt in der Klasse :\staff.

Könnte mir jemand bitte die Standardwerte für OpenBSD 6.3 aus der Klasse :\default posten, damit ich das korrigieren kann?

Danke!
 
Code:
# $OpenBSD: login.conf,v 1.9 2017/02/06 18:11:33 sthen Exp $

#
# Sample login.conf file.  See login.conf(5) for details.
#

#
# Standard authentication styles:
#
# passwd  Use only the local password file
# chpass  Do not authenticate, but change users password (change
#  the YP password if the user has one, else change the
#  local password)
# lchpass  Do not login; change user's local password instead
# radius  Use radius authentication
# reject  Use rejected authentication
# skey  Use S/Key authentication
# activ  ActivCard X9.9 token authentication
# crypto  CRYPTOCard X9.9 token authentication
# snk  Digital Pathways SecureNet Key authentication
# tis  TIS Firewall Toolkit authentication
# token  Generic X9.9 token authentication
# yubikey  YubiKey authentication
#

# Default allowed authentication styles
auth-defaults:auth=passwd,skey:

# Default allowed authentication styles for authentication type ftp
auth-ftp-defaults:auth-ftp=passwd:

#
# The default values
# To alter the default authentication types change the line:
#  :tc=auth-defaults:\
# to be read something like: (enables passwd, "myauth", and activ)
#  :auth=passwd,myauth,activ:\
# Any value changed in the daemon class should be reset in default
# class.
#
default:\
  :path=/usr/bin /bin /usr/sbin /sbin /usr/X11R6/bin /usr/local/bin /usr/local/sbin:\
  :umask=022:\
  :datasize-max=768M:\
  :datasize-cur=768M:\
  :maxproc-max=256:\
  :maxproc-cur=128:\
  :openfiles-max=1024:\
  :openfiles-cur=512:\
  :stacksize-cur=4M:\
  :localcipher=blowfish,a:\
  :tc=auth-defaults:\
  :tc=auth-ftp-defaults:

#
# Settings used by /etc/rc and root
# This must be set properly for daemons started as root by inetd as well.
# Be sure reset these values back to system defaults in the default class!
#
daemon:\
  :ignorenologin:\
  :datasize=infinity:\
  :maxproc=infinity:\
  :openfiles-max=1024:\
  :openfiles-cur=128:\
  :stacksize-cur=8M:\
  :localcipher=blowfish,a:\
  :tc=default:

#
# Staff have fewer restrictions and can login even when nologins are set.
#
staff:\
  :datasize-cur=1536M:\
  :datasize-max=infinity:\
  :maxproc-max=512:\
  :maxproc-cur=256:\
  :ignorenologin:\
  :requirehome@:\
  :tc=default:

#
# Authpf accounts get a special motd and shell
#
authpf:\
  :welcome=/etc/motd.authpf:\
  :shell=/usr/sbin/authpf:\
  :tc=default:

#
# Building ports with DPB uses raised limits
#
pbuild:\
  :datasize-max=infinity:\
  :datasize-cur=4096M:\
  :maxproc-max=1024:\
  :maxproc-cur=256:\
  :tc=default:

#
# Override resource limits for certain daemons started by rc.d(8)
#
bgpd:\
  :openfiles=512:\
  :tc=daemon:

unbound:\
  :openfiles=512:\
  :tc=daemon:

Künftig lieber neue Gruppen anlegen, als bestehende zu ändern :)
Müsste denke ich die originale sein
 
Kleiner Tipp am Rande 2: bester Editor benutzen, emacs, richtig konfiguriert legt der eigene backups an.

In vim nutze ich das so:
Code:
$ mkdir -p ~/.config/vim/tmp/undo

In der ~/.vimrc
Code:
...
if has('persistent_undo') 
    set undofile 
    set undodir=~/.config/vim/tmp/undo// 
endif
...
Nun kann man auch nach Schliessen und erneutem Oeffnen von vim Aenderungen wieder rueckgaengig machen.
 
Noch 2 Tipps:
  1. Die Originale findet man auch auf dem Installationsmedium in etc.tgz
  2. Ich verwalte Änderungen mit RCS.
Code:
mkdir /etc/RCS
ci - l configdatei
vi /etc/configdatei
rcsdiff -u /etc/configdatei
Der letzte Befehl zeigt einem dann die Änderungen.
 
Dazu besser noch ein:
Code:
" Mit Hilfe der viminfo Datei merkt sich Vim Dinge über mehrere
" Sessions hinweg. Wir speichern in ihr:
"
" % - Wir merken uns die Bufferliste, öffnen sie beim Start wieder,
" sofern keine Datei an Vim übergeben wurde.
"
" '128 - Marken der letzten 128 Dateien speichern.
"
" /128 - Die letzten 128 Suchbegriffe.
"
" :128 - Die letzten 128 History-Befehle.
"
" @128 - Die letzten 128 eingegebenen Zeilen.
"
" s1024 - Alle Register bis 1 Megabyte Größe speichern.
set viminfo=%,'128,/128,:128,@128,s1024
Dann werden auch Dinge wie Marken, Register und so weiter persistent gespeichert.
 
Oh je, da habe ich aber dank Eurer Tipps viele Neues zu lernen. Danke dafür.:) Aber unabhängig vom verwendeten Editor ist doch nach Änderung der login.conf immer noch

Code:
cap_mkdb /etc/login.conf

erforderlich, oder?
 
Code:
cap_mkdb /etc/login.conf
erforderlich, oder?
Jaein, kommt auf die Länge deiner login.conf an, ich sage mal bei Configs unter xy Zeilen (1000 oder eher noch mehr?) erreichst du keinen Performancezuwachs und erzeugst einen unnötigen "Overhead".

Hm, das müsste man mal Benchmarken ob man das bei einer SSD überhaupt noch braucht
 
Jaein, kommt auf die Länge deiner login.conf an, ich sage mal bei Configs unter xy Zeilen (1000 oder eher noch mehr?) erreichst du keinen Performancezuwachs und erzeugst einen unnötigen "Overhead".
Gut ich habe mir jetzt mal die Manpage http://man.openbsd.org/OpenBSD-current/man5/login.conf.5 vorgeknöpft, so wie ich es verstehe, kann man optional eine Datenbank verwenden, zwingend vorgeschrieben ist es aber nicht. Genau das wußte ich nicht. Jetzt habe ich die DB verwendet und muß halt darauf achten, das ich nach jeder Änderung die DB aktualisiere.
 
Man muss auch beachten, dass Computer viel, viel schneller geworden sind. Eine VAX aus dem schönen Jahr 1982 hätte für das Einlesen der login.conf vielleicht noch messbar Zeit benötigt, aber eine moderne CPU wacht dafür nicht mal aus dem tiefsten Powerstate auf und braucht dennoch nur Nanosekunden. Wahrscheinlich ist das Lesen der Datei in den RAM sogar langsamer als das Verarbeiten.
 
Wahrscheinlich ist das Lesen der Datei in den RAM sogar langsamer als das Verarbeiten.

Ums mal in Zahlen auszudrücken wie lächerlich selbst das Einlesen in den RAM ist:
Code:
#include <stdio.h>
#include <stdlib.h>

#include <err.h>

int
main(int argc, char *argv[])
{
  if (argc < 2)
      err(EXIT_FAILURE, "argc < 2");

  unsigned long zahl = 0;
  int i, c;
  for (i = 1; i < argc; i++) {
      FILE *read_file;
      read_file = fopen(argv[i], "r");

      while ((c = fgetc(read_file)) != EOF) {
          zahl++;
      }
      fclose(read_file);
  }

  printf("%lu", zahl);
  return EXIT_SUCCESS;
}

Ausgeführt mit:
Code:
time ./test3 `ls`

Ausgabe:
Code:
4772955  0m00.01s real  0m00.01s user  0m00.00s system
4772955 ist die Anzahl der einzeln eingelesenen chars aus allen sichtbaren Files des momentanen Ordners.


Würde man mit ein wenig gefrickel sicher noch schneller bekommen

EDIT: Ist in ner OpenBSD 6.3 VM (Virtualbox) mit 2GB RAM und 1 CPU ausgeführt worden
 
Zuletzt bearbeitet:
Da ich das Tool nicht verwende, stehe ich nun auch echt aufm Schlach wie man Einträge entfernt, die Manpage hilft mir nicht wirklich weiter :)
Wenn ich das mit meinen bescheidenen Englisch Kenntnissen richtig verstanden habe, verhält es sich so:

Wenn Du das erse Mal nach einer Änderung die Datenbank initialisierst und benutzt mit:

Code:
cap_mkdb /etc/login.conf

und später mit einem Editor Deiner Wahl eine erneute Anpassung oder Änderung vornimmst, oder einen Eintrag entfernst, muß zwingend immer wieder danach mit:

Code:
cap_mkdb /etc/login.conf

die Datenbank aktualisiert werden.

Da scheint es mir einfacher, gleich ohne Datenbank zu arbeiten, auch weil es heutzutage keinen messbaren Geschwindigkeitsvorteil mehr gibt.
 
Du kannst einfach die /etc/login.conf.db loeschen und dann kannst Du weiter nur mit der /etc/login.conf arbeiten und musst nicht bei jeder Aenderung ``cap_mkdb /etc/login.conf'' durchfuehren.
 
Du kannst einfach die /etc/login.conf.db loeschen und dann kannst Du weiter nur mit der /etc/login.conf arbeiten und musst nicht bei jeder Aenderung ``cap_mkdb /etc/login.conf'' durchfuehren.
Ha Klasse, und bei einer erneuten Installation Mal ist dann die Datenbank kein Thema mehr und passe. Werde ich sofort durchführen.
 
Ums mal in Zahlen auszudrücken wie lächerlich selbst das Einlesen in den RAM ist:
Code:
#include <stdio.h>
#include <stdlib.h>

#include <err.h>

...

Ich hoffe, dass ich jezt nicht gesteinigt werde, da OT, aber mir ist da [aus didaktischen Gruenden] etwas eingefallen:
Code:
#include <err.h>
#include <stdio.h>
#include <stdlib.h>
#include <sysexits.h>


int
main(int argc, char *argv[])
{
	unsigned long zahl;
	int i, c;
	FILE *read_file;
 
	if (argc < 2)
		errx(EX_USAGE, "%s, argc < 2", __func__);

	zahl = 0;
  
	for (i = 1; i < argc; i++) {
		read_file = fopen(argv[i], "r");
		if (read_file < 0) {
			errx(EX_NOINPUT, "%s: fopen(3)", __func__);
		}
		
		while ((c = fgetc(read_file)) != EOF) {
			zahl++;
		}

		if (fclose(read_file) < 0) {
/*
 * Exception Handling waere mMn _hier_ ueberfluessig, da die
 * Datei existiert, wobei es mir darum geht das Verwenden von
 * in include/sysexits.h definierten Codes zu inspirieren. 
 */ 			 
			errx(EX_NOINPUT, "%s: fclose(3)", __func__);
		}
	}

	(void)printf("%lu", zahl);

	exit(EX_OK);

	/* NOTREACHED */
}
Das Programm ist schoen, wobei ich bzgl. Exception Handling das Programm etwas ergaenzte, weil sich sysexits(3) im Zusammenhang mit Debugging oder dem Implementieren von Software als [hoffentlich] sinnvolle Ergaenzung bzw. hilfreich erweisen kann. :)

Die Capability database syntax ist ein "interessantes" Thema, denn die in login.conf(5) enthaltenen Informationen [wie bereits von @TCM erwaehnt wurde], werden mittels Funktionen dieser API in eine Datenbank ueberfuehrt, die eine Teilmenge von Funktionen der bspw. von *r*cl* als Produkt vermarkteten Berkeley DB implementiert [als ich das endeckte, war ich "irritiert", dass das Produkt mMn noch nicht von *r*cl* geschrottet wurde *scnr*], was ermoeglicht [bestenfalls] mit einer Kopie der Capability database zu "experimentieren", wofuer die Implementierung von cap_mkdb(1) oder die von finger(1) eine Steilvorlage boete.
 
Zuletzt bearbeitet von einem Moderator:
Unsere beiden Beispiele haben keinen Error-Handler, falls das read_file nicht existiert *duck und weg* :ugly:

Das Programm ist schoen, wobei ich bzgl. Exception Handling das Programm etwas ergaenzte, weil sich sysexits(3) im Zusammenhang mit Debugging oder dem Implementieren von Software als [hoffentlich] sinnvolle Ergaenzung bzw. hilfreich erweisen kann. :)
Vielen Dank, den Tipp nehme ich gerne mit, Portierbarkeit ist mir ohnehin nicht wichtig
 
Je verstaendlicher [Portierbarkeit] der Quellcode ist, je erfolgreicher das Peer-Review, da oftmals selbst einem Fehler im Quelltext nicht auffallen, weil man ja manchmal den Wald vor lauter Baeumen nicht sehe?
 
Zuletzt bearbeitet von einem Moderator:
Zurück
Oben