Re: OT: X aperture
On Thursday 24 July 2003 07:53 am, [EMAIL PROTECTED] wrote: > Hello again! > Sorry for trolling. > I have just found one more way to have X and seculevel coexisting. > It's applicable for desktops mostly.Here's the trick: > Start the system with seculevel "-1", run startx and then type > '/sbin/sysctl -w kern.securelevel=1' in a terminal. The last requires as > all know requires root privileges or sudo. Yes, already said that. But if the X server crashes or exits, you won't be able to start it again without rebooting. That's why OpenBSD's APERTURE option is superior. > Thanks for your patience, > Dimitar Vassilev -- Farid Hajji. http://www.farid-hajji.net/address.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: login(1) doesn't enforce times.allow/times.deny over ssh(1)
On Sunday 20 July 2003 09:38 pm, Doug White wrote: > On Sun, 20 Jul 2003, Farid Hajji wrote: > > When using ssh, I'm not trying public/private keys, > > just plain unix passwords. Doesn't ssh access login(1) > > in this case? > > sshd does not use login unless requested to do so by the UseLogin config > parameter. Ye, that was it. > There have been security vulnerabilities exposed by using this option in > the past. You have been warned :) So we need an additional pam module for such policy settings. That's reasonable. Many thanks. -- Farid Hajji. http://www.farid-hajji.net/address.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
login(1) doesn't enforce times.allow/times.deny over ssh(1)
I'm trying to set up a login class on 5.1-R which limits users from logging in at night or on week ends. Unfortunately, the time limits are not enforced by login(1), when the host is accessed via ssh (only from the console are the time limits enforced): In /etc/login.conf, I've set this: time_limited:\ :welcome=/root/motd-timelimited:\ :times.allow=MoTuWeThFr0800-1900:\ :times.deny=So-2359:\ :tc=default: and ran 'cap_mkdb /etc/login.conf' as instructed. Changed login class of some test users with chsh(1). The change in the 'welcome' capability works all right, but not the time limitations (when using ssh). I'm using the default /etc/pam.d/login, as of 5.1-R, where pam_ssh.so is always commented out. When using ssh, I'm not trying public/private keys, just plain unix passwords. Doesn't ssh access login(1) in this case? Do you have an idea what's wrong here, or, better yet, a solution? Many thanks. -- Farid Hajji. http://www.farid-hajji.net/address.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: OT:escaping X barfings
> > CAn you tell me how a procedure how to patch X and kernel > > to avoid X barfings from securelevel? My release is a FreeBSD 5.1. > > 2) adding `options APERTURE` to my kernel > > 3) make buildkernel && make install kernel && make > > buildworld 4) reboot and face the music > > Do as you feel you must, but I installed 5.1-RELEASE and X from ports and > it's running fine. Are you starting from a terminal with 'startx' or do > you start xdm at boot? If you use startx, I believe you need to install > x-wrapper to get around permission issues. This is a FAQ. X needs to access /dev/io, which is not possible if securelevel is raised. You need to startx/gdm and _then_ raise securelevel. This is not flexible, because if X server crashes, you can't start it again without rebooting. OpenBSD provides an option 'APERTURE' which allows X to start even when securelevel is >0. I wish we would have that as well... -- Farid Hajji. http://www.farid-hajji.net/address.html ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Serious ppp failure on 5.1
"P.U.Kruppa" <[EMAIL PROTECTED]> writes: > after a cvsup to 5.1-CURRENT my ppp over ethernet doesn't connect > anymore. > Using ppp manually I receive: > Unexpected node type "socket" (wanted "ether") > The connection works fine on my 4.8 with identical ppp.conf . I can confirm that 4.8-STABLE as of Mon Jun 9 04:43:55 CEST 2003 works fine. I'm using the same ppp.conf than yours, even the same DSL provider (kamp-dsl). Ugh, I was just planning to switch to 5.1-RELEASE and cvsup to CURRENT. Now, I'm reluctant to do this for my DSL router -STABLE box. Thanks for the HEADSUP :-) > What can I do ? What does kldstat say? This is what I have on -STABLE: 1 30 0xc010 434cb4 kernel 24 0xc10ca000 9000 netgraph.ko 31 0xc10d7000 3000 ng_ether.ko 41 0xc10dc000 5000 ng_pppoe.ko 51 0xc10e2000 3000 ng_socket.ko 61 0xc114a000 15000linux.ko Did you try to kldload any missing modules manually? > |Peter Ulrich Kruppa| > | - Wuppertal - | > | Germany | -FH. -- Farid Hajji -- Unix Systems and Network Management. http://www.farid-hajji.net/address.html Quoth the Raven, "Nevermore." --Edgar Allan Poe. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
OpenSSL CA.pl only in src dir?
Hi,
is there any reason, why
/usr/src/crypto/openssl/apps/CA.{sh,pl}
are not installed outside /usr/src?
Some end users may not install src,
yet still need this wrapper...
Thanks,
-FH
--
Farid Hajji -- Unix Systems and Network Management.
http://www.farid-hajji.net/address.html
Quoth the Raven, "Nevermore." --Edgar Allan Poe.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Kernel panic while dumping (even in single user mode).
known: can't assign resources unknown: can't assign resources sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm1: on sbc0 ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable ad0: 19464MB [39546/16/63] at ata0-master WDMA2 acd0: CDROM at ata0-slave using PIO3 Waiting 8 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0s1a cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-2 device da0: 40.000MB/s transfers (20.000MHz, offset 8, 16bit), Tagged Queueing Enabled da0: 2063MB (4226725 512 byte sectors: 255H 63S/T 263C) I'm trying to dump an IDE drive (main drive) on an msdos filesystem written on a SCSI disk (ahc driver). This is the command (in single user mode!) that caused the dump: # cd /msdos/dump/dump.8 # dump -0u -B 1000 -f usr-fs.l0.dump /usr /usr was not even mounted at this time. I just upgraded from CURRENT 2001-01-25 to 2001-02-18:0100 CET. Everything else _seems_ to work sofar (no libc problems etc...). The panic is new (I've never had a panic in this situation with the old kernel). The error above is reproducible. Another problem is when shutting down: at least one buffer is never flushed => enforcing fsck at next reboot. Something's wrong. What's going on here? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Make kernel fail in modules after upgrade 4.2 -> 5.0
> During the fixing stages of the libc problem, vinum caused panics fairly > regularly for me (very early on or during fsck). > > I'm now seeing panics in ufs write after medium heavy activity (make world, > no -j) on SMP, no reg dump comes out. Complains about table inconsistent > (don't remember the precise message). Hopefully my hardware is OK; this > machine has been stable for several weeks with upgraded RAM. I've just upgraded from 2001-01-25 to 2001-02-18:0100 CET and everyting seemed to work fine for me... Well, that was not true: The new kernel panics during dump(8), even when running in single user mode. This error is reproducible, though not at exactly the same number of dumped bytes (the dump file is more or less big). Shutting down now frequently leaves unflushed buffers too. I'm just rebuilding with DDB now... Anyone experiencing problems while dumping? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: -current world broken since Feb 10
Hi, I just updated -CURRENT 2001-01-25 to 2001-02-18.0100 CET and the system runs fine for me. Built and installed kernel too. All old binaries that linked to libc.so.5 (including X11) not recompiled; they still run fine. No problems with as(1) either. The only glitch during installworld was: install: /usr/share/examples/BSD_daemon/FreeBSD.pfa: No such file or directory Error Code 71 and other errors in /usr/share/examples/BSD_daemon about missing files. make -k buileworld did the trick just fine. Other errors (besides BSD_daemon) didn't occur during buildworld. > > > FreeBSD .whacky.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Fri Feb 16 >14:33:37 CET 2001 >stephanb@.whacky.net:/mnt/archive/CVS/CURRENT/src/sys/compile/ i386 Here too: FreeBSD bsdevil.meta.net 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sun Feb 18 22:04:15 CET 2001 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYTWR i386 > > If you want to discover and reproduce the problem (:-) > > it is sufficient to go to ports/devel/gettext and 'make' this port. > > When make start to make in the 'po' directory it SIGFAULTs in > > __ungetc. > > *sighs* True.. it fails here as well. Damn This works fine here (gettext-0.10.35.tar.gz). No problems whatsoever recompiling... Regards, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Strange fopen() behaviour
> dev.lan.Awfulhak.org kernel log messages: > > microuptime() went backwards (18415.166882 -> 18415.158249) > > microuptime() went backwards (18490.192910 -> 18490.187579) > > microuptime() went backwards (19572.644000 -> 19572.638237) > > microuptime() went backwards (19878.637972 -> 19878.637330) > > microuptime() went backwards (20043.869158 -> 20043.868971) > > microuptime() went backwards (20074.159108 -> 20074.152253) > > microuptime() went backwards (20210.078270 -> 20210.072448) I'm also seing this as of CURRENT-2001-01-27 and later: pcm1: hwptr went backwards 36 -> 0 pcm1: hwptr went backwards 40 -> 16 pcm1: hwptr went backwards 2084 -> 2048 pcm1: hwptr went backwards 2092 -> 2064 Strange... -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel hangs initializing Soundblaster AWE 64 midi driver
Hi, I'm tracking -CURRENT and build a kernel yesterday with the following options (edited): device sbc # Soundblaster Bridge-Code to pcm device pcm # PnP/PCI Sound Cards #device midi# Midi interfaces #device seq # Sequencer The corresponding hints are: Without midi device, this is the relevant dmesg part: [...] vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b \ irq 5 drq 1,5 on isa0 pcm1: on sbc0 unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources unknown: can't assign resources ed0 XXX: driver didn't initialize queue mtx lp0 XXX: driver didn't initialize queue mtx lo0 XXX: driver didn't initialize queue mtx ata0-master: DMA limited to UDMA33, non-ATA66 compliant cable [...] and the kernel happily boots. Sound is usable as before. Now, adding midi (either alone or together with seq) produces the following messages: sbc0: at port 0x220-0x22f,0x330-0x331,0x388-0x38b \ irq 5 drq 1,5 on isa0 pcm1: on sbc0 midi0: on sbc0 midi1: on sbc0 midi2: at port 0x620-0x623 on isa0 exactly here, the system hangs completely. What I'm I missing? Thanks, -Farid. -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
buildworld failed with sysinstall
Hello, 'make buildworld' failed while trying to comple sysinstall: cc -O -pipe -Wall -I/usr/src/usr.sbin/sysinstall/../../gnu/lib/libdialog -I. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/sysinstall/keymap.c In file included from /usr/src/usr.sbin/sysinstall/keymap.c:40: keymap.h:3239: `keymap_us_pc_ctrl' undeclared here (not in a function) keymap.h:3239: initializer element is not constant keymap.h:3239: (near initialization for `keymapInfos[23].map') *** Error code 1 Stop in /usr/src/usr.sbin/sysinstall. *** Error code 1 cvsupped -CURRENT, 2001-01-25:1811 trying to update an old -CURRENT-2506 source tree. Any ideas? -- Farid Hajji -- Unix Systems and Network Admin | Phone: +49-2131-67-555 Broicherdorfstr. 83, D-41564 Kaarst, Germany | [EMAIL PROTECTED] - - - - - - - - - - - - - - - - - - - - - - - + - - - - - - - - - - - - Murphy's Law fails only when you try to demonstrate it, and thus succeeds. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
