Re: [RFC] last(1) with security.bsd.see_other_uids support
2012/6/5 Jilles Tjoelker : > To avoid this, the utmpx APIs could communicate with a privileged daemon > if the files are not readable. The daemon can check the identity of the > caller via getpeereid(3). +1. I would really like to have something like this. Another advantage of this approach would be that it's a lot easier to change the file format then. There's only one application that interacts with these files. -- Ed Schouten ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [RFC] last(1) with security.bsd.see_other_uids support
2012/6/6 Pawel Jakub Dawidek : > Any privileged daemon is much bigger threat. Also, do we really want a > daemon running all the time just to be able to parse utx files? Well, if you think of it, it's not a very strange idea: - You can simply get rid of /var/run/utx.active. There's no need for this to be written to disk. It can just stay in memory. - You can use devd to track the destruction of TTYs, so you can automatically garbage collect stale entries for pseudo-terminals. Right now a `killall -9 xterm' may leave stale entries behind. - The other files aren't _that_ big. On FreeBSD, utx.log only stores entries for the last month. Especially if you implement getutxid()/getutxuser() as separate calls, much of the filtering is already done by the daemon. -- Ed Schouten ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
boot menu option to disable graphics mode
It's long been a wish of mine to have an ability to decide at boot time that a system should boot in "console-only" mode. That is, that no graphics/X applications like e.g. xdm/kdm/gdm are automatically started even when they are configured to do so. Here is my attempt at implementing that: https://gitorious.org/~avg/freebsd/avgbsd/commit/96f7051d63d4286ef6f0196d241e7855338a6ed7?format=patch All the option does at boot time is setting of 'inhibit_gui' variable for kernel environment. I envision that this variable could be properly and gracefully handled in various startup scripts and/or application startup logic. But to ensure that the option is always honored I've also added "ultimate protection" to syscons that prohibits KDSETMODE/KD_GRAPHICS ioctl. What do you think? -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On Thu, Jun 07, 2012 at 10:45:26AM +0300, Andriy Gapon wrote: > > It's long been a wish of mine to have an ability to decide at boot time that a > system should boot in "console-only" mode. That is, that no graphics/X > applications like e.g. xdm/kdm/gdm are automatically started even when they > are > configured to do so. > > Here is my attempt at implementing that: > https://gitorious.org/~avg/freebsd/avgbsd/commit/96f7051d63d4286ef6f0196d241e7855338a6ed7?format=patch > > All the option does at boot time is setting of 'inhibit_gui' variable for > kernel > environment. I envision that this variable could be properly and gracefully > handled in various startup scripts and/or application startup logic. > But to ensure that the option is always honored I've also added "ultimate > protection" to syscons that prohibits KDSETMODE/KD_GRAPHICS ioctl. This is too much, IMO. I understand why you may want to disable auto-start of login manager, but preventing a user from running X at all until she learns about kenv -u _and_ obscure code somewhere in the kernel, is unreasonable. pgpGQ5pmj2pYb.pgp Description: PGP signature
Re: boot menu option to disable graphics mode
on 07/06/2012 11:47 Konstantin Belousov said the following: > On Thu, Jun 07, 2012 at 10:45:26AM +0300, Andriy Gapon wrote: >> >> It's long been a wish of mine to have an ability to decide at boot time that >> a >> system should boot in "console-only" mode. That is, that no graphics/X >> applications like e.g. xdm/kdm/gdm are automatically started even when they >> are >> configured to do so. >> >> Here is my attempt at implementing that: >> https://gitorious.org/~avg/freebsd/avgbsd/commit/96f7051d63d4286ef6f0196d241e7855338a6ed7?format=patch >> >> All the option does at boot time is setting of 'inhibit_gui' variable for >> kernel >> environment. I envision that this variable could be properly and gracefully >> handled in various startup scripts and/or application startup logic. >> But to ensure that the option is always honored I've also added "ultimate >> protection" to syscons that prohibits KDSETMODE/KD_GRAPHICS ioctl. > This is too much, IMO. I understand why you may want to disable > auto-start of login manager, but preventing a user from running X at all > until she learns about kenv -u _and_ obscure code somewhere in the kernel, > is unreasonable. A user doesn't have to select the option unless he needs to. A "simple user" can just reboot without selecting the option to get back his X. A user doesn't have to learn anything about the code, just about kenv and "magic" inhibit_gui variable. IMO. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On (07/06/2012 11:56), Andriy Gapon wrote: > on 07/06/2012 11:47 Konstantin Belousov said the following: > > On Thu, Jun 07, 2012 at 10:45:26AM +0300, Andriy Gapon wrote: > >> > >> It's long been a wish of mine to have an ability to decide at boot time > >> that a > >> system should boot in "console-only" mode. That is, that no graphics/X > >> applications like e.g. xdm/kdm/gdm are automatically started even when > >> they are > >> configured to do so. > >> > >> Here is my attempt at implementing that: > >> https://gitorious.org/~avg/freebsd/avgbsd/commit/96f7051d63d4286ef6f0196d241e7855338a6ed7?format=patch > >> > >> All the option does at boot time is setting of 'inhibit_gui' variable for > >> kernel > >> environment. I envision that this variable could be properly and > >> gracefully > >> handled in various startup scripts and/or application startup logic. > >> But to ensure that the option is always honored I've also added "ultimate > >> protection" to syscons that prohibits KDSETMODE/KD_GRAPHICS ioctl. > > This is too much, IMO. I understand why you may want to disable > > auto-start of login manager, but preventing a user from running X at all > > until she learns about kenv -u _and_ obscure code somewhere in the kernel, > > is unreasonable. > > A user doesn't have to select the option unless he needs to. > A "simple user" can just reboot without selecting the option to get back his > X. > A user doesn't have to learn anything about the code, just about kenv and > "magic" inhibit_gui variable. What do you think about adding generic support for overriding *_enable options in rc.conf? I'd like to be able to disable services at boot prompt, e.g. # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf Similarly rc.pf_enable="no" Then introduce x_enable knob (=yes by default) to disable login managers. User will be able to override this setting with # service xdm forcestart Thanks, Gleb. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
on 07/06/2012 12:57 Gleb Kurtsou said the following: > What do you think about adding generic support for overriding *_enable > options in rc.conf? > > I'd like to be able to disable services at boot prompt, e.g. > # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf > > Similarly rc.pf_enable="no" > > Then introduce x_enable knob (=yes by default) to disable login > managers. User will be able to override this setting with > # service xdm forcestart I think that this is an excellent idea. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Wide character types
On 6 June 2012 12:03, Andrew Turner wrote: > I've been working on getting the ARM EABI working with FreeBSD. > > As part of the EABI spec the Procedure Call Standard for the ARM > Architecture (AAPCS) defines wchar_t as either an unsigned int or an > unsigned short with the former as the preferred type. FreeBSD defines > wchar_t as a __wchar_t, which is defined as a __ct_rune_t, which is > defined as an int. > > wint_t and rune_t are also defined in terms of __ct_rune_t. wint_t must > be a signed type as it needs to hols a WEOF which is defined as -1. > > The type of rune_t appears to need to be the same as wint_t as the tow* > and isw* functions are defined as taking a wint_t by the documentation > but __ct_rune_t in the code and compare this value against __rune_t > values. > > My question is am I correct in thinking rune_t and wint_t should be > defined as __ct_rune_t with __ct_rune_t defined as an int while wchar_t > should be defined as an unsigned int in ARM EABI and defined as an int > elsewhere? Non-authoritative answer: I think you conclusion is correct. I think that freebsd-standa...@freebsd.org would be a better audience for this kind of question. -- VZ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CD bootcode
On Wednesday, June 06, 2012 12:15:14 pm rank1see...@gmail.com wrote: > FreeBSD's CD bootcode '/boot/cdboot' is targeting stage 3 boot -> loader > For example, stage 2 boot '/boot/boot' is attempting the same. > > In my case of a '/boot/loader', '/boot' is a symlink! > > So if '/boot/boot' works with symlinks, why '/boot/cdboot' doesn't! > Yes, I did use Rock-Ridge extensions, upon creation of 'cd.iso' Because I didn't make cdboot's lookup routine handle symlinks. It also doesn't look at Rock-Ridge extensions and only uses the base ISO-9660 directory entries. That was enough fun to write in assembly. OTOH, CD sectors are 2k, so you do have that much room to work with and can probably fit a more advanced directory lookup into cdboot. I'm happy to review any patches you come up with. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CD bootcode
- Original Message - From: John Baldwin To: freebsd-hackers@freebsd.org Cc: rank1see...@gmail.com Date: Thu, 7 Jun 2012 08:21:39 -0400 Subject: Re: CD bootcode > On Wednesday, June 06, 2012 12:15:14 pm rank1see...@gmail.com wrote: > > FreeBSD's CD bootcode '/boot/cdboot' is targeting stage 3 boot -> loader > > For example, stage 2 boot '/boot/boot' is attempting the same. > > > > In my case of a '/boot/loader', '/boot' is a symlink! > > > > So if '/boot/boot' works with symlinks, why '/boot/cdboot' doesn't! > > Yes, I did use Rock-Ridge extensions, upon creation of 'cd.iso' > > Because I didn't make cdboot's lookup routine handle symlinks. It > also doesn't look at Rock-Ridge extensions and only uses the base > ISO-9660 directory entries. That was enough fun to write in assembly. > OTOH, CD sectors are 2k, so you do have that much room to work with > and can probably fit a more advanced directory lookup into cdboot. > > I'm happy to review any patches you come up with. > > -- > John Baldwin I need to correct myself. BOTH stage 2 boot '/boot/boot' AND '/boot/cdboot' don't work with symlinks! '/boot/boot' on UFS sees symlink as file, same as '/boot/cdboot' does so on Rock-Ridge. I can handle '/boot/boot' by providing full path to loader via 'boot.config' '/boot/cdboot' doesn't have such a file, so in '/usr/src/sys/boot/i386/cdboot/cdboot.s': -- loader_paths: .asciz "/BOOT/LOADER" .asciz "/boot/loader" .byte 0 -- I injected third '.asciz' line with full path to 'loader' and recompiled it. And what is first line "/BOOT/LOADER" doing in there ?!? But even when loader is finally started, loader handles symlinks on UFS (kicked by '/boot/boot'), BUT fails so, on Rock-Ridge iso (kicked by '/boot/cdboot') Looks like loader must be made into looking at Rock-Ridge extensions. I can't provide patches, as I only know 'sh', 'php' (and web related langs) Above code I've patched, only because I've hunted patterns. Domagoj Smolčić ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On 06/07/2012 02:57 AM, Gleb Kurtsou wrote: > What do you think about adding generic support for overriding *_enable > options in rc.conf? > > I'd like to be able to disable services at boot prompt, e.g. > # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf > > Similarly rc.pf_enable="no" > > Then introduce x_enable knob (=yes by default) to disable login > managers. User will be able to override this setting with > # service xdm forcestart Why not just: boot single user fsck -p mount -a $EDITOR /etc/rc.conf[.local] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
ifconfig accepting hostname as ipv4 address
Hello list! Since the early days ifconfig(8) has the following functionality: .. address For the DARPA-Internet family, the address is either a host name present in the host name data base, hosts(5), or a DARPA Internet address expressed in the Internet standard “dot notation”. E.g. one can write `ifconfig em0 some_possibly_unqualified_fqdn` and get inet address assigned to the card with classful mask. Now this can lead to "fun" things if you have misprinted some keyword and this keyword exists in the local DNS zone (or wildcard is configured). The most favorite one (we have wilcard configured in one of our search zones): 18:45 [0] dhcp170-36-red# ifconfig vlan123 desroy 18:45 [0] dhcp170-36-red# echo $? 0 18:45 [0] dhcp170-36-red# ifconfig vlan123 vlan123: flags=8003 metric 0 mtu 1500 ether 00:00:00:00:00:00 inet 213.180.204.242 netmask 0xff00 broadcast 213.180.204.255 inet6 fe80::222:4dff:fe50:cd2f%vlan123 prefixlen 64 scopeid 0xd nd6 options=21 vlan: 0 parent interface: This is also one of the reasons why ifconfig sometimes "hangs" on invalid input. Moreover, ifconfig em0 some_valid_fqdn/MASK silently ignores it, so you can't set valid CIDR address using this notation. Classful era has ended more than 10 years ago, do we still want to keep this behavior? -- WBR, Alexander ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On Thu, Jun 7, 2012 at 7:29 AM, Doug Barton wrote: > On 06/07/2012 02:57 AM, Gleb Kurtsou wrote: >> What do you think about adding generic support for overriding *_enable >> options in rc.conf? >> >> I'd like to be able to disable services at boot prompt, e.g. >> # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf >> >> Similarly rc.pf_enable="no" >> >> Then introduce x_enable knob (=yes by default) to disable login >> managers. User will be able to override this setting with >> # service xdm forcestart > > Why not just: > > boot single user > fsck -p > mount -a > $EDITOR /etc/rc.conf[.local] I've run into _multiple_ scenarios where this isn't possible because the terminal settings are screwed up in single user mode, and had to resort to `sed -i '' `. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On Thu, Jun 7, 2012 at 2:57 AM, Gleb Kurtsou wrote: > On (07/06/2012 11:56), Andriy Gapon wrote: >> on 07/06/2012 11:47 Konstantin Belousov said the following: >> > On Thu, Jun 07, 2012 at 10:45:26AM +0300, Andriy Gapon wrote: >> >> >> >> It's long been a wish of mine to have an ability to decide at boot time >> >> that a >> >> system should boot in "console-only" mode. That is, that no graphics/X >> >> applications like e.g. xdm/kdm/gdm are automatically started even when >> >> they are >> >> configured to do so. >> >> >> >> Here is my attempt at implementing that: >> >> https://gitorious.org/~avg/freebsd/avgbsd/commit/96f7051d63d4286ef6f0196d241e7855338a6ed7?format=patch >> >> >> >> All the option does at boot time is setting of 'inhibit_gui' variable for >> >> kernel >> >> environment. I envision that this variable could be properly and >> >> gracefully >> >> handled in various startup scripts and/or application startup logic. >> >> But to ensure that the option is always honored I've also added "ultimate >> >> protection" to syscons that prohibits KDSETMODE/KD_GRAPHICS ioctl. >> > This is too much, IMO. I understand why you may want to disable >> > auto-start of login manager, but preventing a user from running X at all >> > until she learns about kenv -u _and_ obscure code somewhere in the kernel, >> > is unreasonable. >> >> A user doesn't have to select the option unless he needs to. >> A "simple user" can just reboot without selecting the option to get back his >> X. >> A user doesn't have to learn anything about the code, just about kenv and >> "magic" inhibit_gui variable. > > What do you think about adding generic support for overriding *_enable > options in rc.conf? > > I'd like to be able to disable services at boot prompt, e.g. > # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf > > Similarly rc.pf_enable="no" > > Then introduce x_enable knob (=yes by default) to disable login > managers. User will be able to override this setting with > # service xdm forcestart It needs to be profiled, but I would be curious what the slowdown would be for this change. Also, it sort of introduces a fun chicken and egg problem with sourcing rc.conf files, like I discovered recently at $JOB. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CD bootcode
On Jun 7, 2012 2:58 PM, wrote: > > - Original Message - > From: John Baldwin > To: freebsd-hackers@freebsd.org > Cc: rank1see...@gmail.com > Date: Thu, 7 Jun 2012 08:21:39 -0400 > Subject: Re: CD bootcode > > > On Wednesday, June 06, 2012 12:15:14 pm rank1see...@gmail.com wrote: > > > FreeBSD's CD bootcode '/boot/cdboot' is targeting stage 3 boot -> loader > > > For example, stage 2 boot '/boot/boot' is attempting the same. > > > > > > In my case of a '/boot/loader', '/boot' is a symlink! > > > > > > So if '/boot/boot' works with symlinks, why '/boot/cdboot' doesn't! > > > Yes, I did use Rock-Ridge extensions, upon creation of 'cd.iso' > > > > Because I didn't make cdboot's lookup routine handle symlinks. It > > also doesn't look at Rock-Ridge extensions and only uses the base > > ISO-9660 directory entries. That was enough fun to write in assembly. > > OTOH, CD sectors are 2k, so you do have that much room to work with > > and can probably fit a more advanced directory lookup into cdboot. > > > > I'm happy to review any patches you come up with. > > > > -- > > John Baldwin > > > I need to correct myself. > BOTH stage 2 boot '/boot/boot' AND '/boot/cdboot' don't work with symlinks! > > '/boot/boot' on UFS sees symlink as file, same as '/boot/cdboot' does so on Rock-Ridge. > > I can handle '/boot/boot' by providing full path to loader via 'boot.config' > '/boot/cdboot' doesn't have such a file, so in '/usr/src/sys/boot/i386/cdboot/cdboot.s': > -- > loader_paths: .asciz "/BOOT/LOADER" >.asciz "/boot/loader" >.byte 0 > -- > > I injected third '.asciz' line with full path to 'loader' and recompiled it. > And what is first line "/BOOT/LOADER" doing in there ?!? > Because strict ISO9660 8.3 is case insensitive and uses caps? Chris ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On 06/07/2012 08:12 AM, Garrett Cooper wrote: > I've run into _multiple_ scenarios where this isn't possible because > the terminal settings are screwed up in single user mode, and had to > resort to `sed -i '' `. If that happens, a) report it! SUM is a very important part of FreeBSD, and it needs to always work. b) There were problems after the cons25 -> xterm conversion that have almost all been fixed nowadays c) Try using a simpler shell, like /bin/sh, or even /rescue/sh d) Obviously don't try to do SUM with a shell that is not compiled static hth, Doug ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: CD bootcode
On Thursday, June 07, 2012 9:58:25 am rank1see...@gmail.com wrote: > - Original Message - > From: John Baldwin > To: freebsd-hackers@freebsd.org > Cc: rank1see...@gmail.com > Date: Thu, 7 Jun 2012 08:21:39 -0400 > Subject: Re: CD bootcode > > > On Wednesday, June 06, 2012 12:15:14 pm rank1see...@gmail.com wrote: > > > FreeBSD's CD bootcode '/boot/cdboot' is targeting stage 3 boot -> loader > > > For example, stage 2 boot '/boot/boot' is attempting the same. > > > > > > In my case of a '/boot/loader', '/boot' is a symlink! > > > > > > So if '/boot/boot' works with symlinks, why '/boot/cdboot' doesn't! > > > Yes, I did use Rock-Ridge extensions, upon creation of 'cd.iso' > > > > Because I didn't make cdboot's lookup routine handle symlinks. It > > also doesn't look at Rock-Ridge extensions and only uses the base > > ISO-9660 directory entries. That was enough fun to write in assembly. > > OTOH, CD sectors are 2k, so you do have that much room to work with > > and can probably fit a more advanced directory lookup into cdboot. > > > > I'm happy to review any patches you come up with. > > > > -- > > John Baldwin > > > I need to correct myself. > BOTH stage 2 boot '/boot/boot' AND '/boot/cdboot' don't work with symlinks! Correct. > '/boot/boot' on UFS sees symlink as file, same as '/boot/cdboot' does so on > Rock-Ridge. > > I can handle '/boot/boot' by providing full path to loader via 'boot.config' > '/boot/cdboot' doesn't have such a file, so in > '/usr/src/sys/boot/i386/cdboot/cdboot.s': > -- > loader_paths: .asciz "/BOOT/LOADER" > .asciz "/boot/loader" > .byte 0 > -- > > I injected third '.asciz' line with full path to 'loader' and recompiled it. > And what is first line "/BOOT/LOADER" doing in there ?!? Plain ISO-9660 always uses uppercase letters for filenames. There is a mkisofs flag to use lowercase, but by default it uppercases all filenames. > But even when loader is finally started, loader handles symlinks on UFS > (kicked by '/boot/boot'), BUT fails so, on Rock-Ridge iso (kicked by '/boot/cdboot') > Looks like loader must be made into looking at Rock-Ridge extensions. It is src/lib/libstand/cd9660.c that would have to be patched. It already has limited Rock-Ridge support, so adding symlink support to cd9660_open() may not be that hard to do. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
on 07/06/2012 17:29 Doug Barton said the following: > On 06/07/2012 02:57 AM, Gleb Kurtsou wrote: >> What do you think about adding generic support for overriding *_enable >> options in rc.conf? >> >> I'd like to be able to disable services at boot prompt, e.g. >> # set rc.slim_enable="no" -- overrides slim_enable="yes" in rc.conf >> >> Similarly rc.pf_enable="no" >> >> Then introduce x_enable knob (=yes by default) to disable login >> managers. User will be able to override this setting with >> # service xdm forcestart > > Why not just: > > boot single user > fsck -p > mount -a > $EDITOR /etc/rc.conf[.local] > Ah, right. Why provide a way to do something using one command at one prompt (or even toggling a menu option using a single keystroke) when you can already do the same using multiple commands at multiple places (and also trying to not forget to undo your changes later)... -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: boot menu option to disable graphics mode
On Thu, Jun 07, 2012 at 10:45:26AM +0300, Andriy Gapon wrote: > > It's long been a wish of mine to have an ability to decide at boot time that a > system should boot in "console-only" mode. That is, that no graphics/X > applications like e.g. xdm/kdm/gdm are automatically started even when they > are > configured to do so. > > Here is my attempt at implementing that: > https://gitorious.org/~avg/freebsd/avgbsd/commit/96f7051d63d4286ef6f0196d241e7855338a6ed7?format=patch > > All the option does at boot time is setting of 'inhibit_gui' variable for > kernel > environment. I like this idea. rc(8) sets rc_fast=yes when the system boots, so it would be possible to extend the scripts that start a desktop manager can use a code like this: if [ -n "$rc_fast" -a "`kenv inhibit_gui 2> /dev/null`" = "1" ]; then echo "Console only mode, $name not started" exit 0 fi Then the user can still start the DM manually by issuing "service $name start". pgp6ER3Vv2RPM.pgp Description: PGP signature
nss compat shims
Hi, I'm currently implementing support for more NSS databases in net/nss-pamd-ldapd and I've started to wonder why there's only the group and password support in lib/libc/net/nss_compat.c? Is there a specific reason for it or is this a classic case of "patches welcome"? I wasn't able to determine the reason from the commit log. -- Mel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
disabling generic attach for hptrr
I was sent this patch by a user that has been having trouble with his hardware until attach_generic was disabled in loader.conf. Is there any reason to have this on by default? Would anyone object to me committing this patch? -- Eitan Adler freebsd-9.0-disable-hptrr-generic-attach.patch Description: Binary data ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
