Re: misc/41772: can't disable keybell [PATCH]
> Using kbdcontrol -b off on my laptop running current does
> turn off the sound already.
I tested `kbdcontrol -b off` on FreeBSD 5.0-RELEASE, and it
still did not turn off the beeper. I have also checked
'syscons.c', v. 1.399 ([0]), and foud only one change
concerning keybell:
'if (cold || shutdown_in_progress || !enable_bell)' -
('enable_bell' added, which must be "hw.syscons.bell"
sysctl var), that enables to turn the keybell off globally,
but not for separate vtys.
> Incidentally, using quiet.off doesn't
> shut it up either which is very confusing since quiet sets
> SC_QUIET_BELL.
I tested this again, and it works fine:
`kbdcontrol -b quiet.normal`
`(sleep 2;echo -e "\x07";sleep 2)&`
When, after executing this command, i quickly switch to
another vty, I hear no bell; when I stay on the same vty,
I can hear the bell.
> PCI ID's for the ICH4 controllere were committed prior to 4.7.
good, found my controller's ID in the latest CVSweb ATA-PCI tree
> This patch would inadvertently turn off visual bell's if you
> set the duration or pitch to zero manually. A better patch
> might be:
>
> Index: syscons.c
> ===
> RCS file: /usr/cvs/src/sys/dev/syscons/syscons.c,v
> retrieving revision 1.399
> diff -u -r1.399 syscons.c
> --- syscons.c 3 Mar 2003 16:24:44 - 1.399
> +++ syscons.c 22 Mar 2003 14:38:58 -
> @@ -3547,7 +3547,7 @@
> if (scp != scp->sc->cur_scp)
> scp->sc->blink_in_progress += 2;
> blink_screen(scp->sc->cur_scp);
> -} else {
> +} else if (duration != 0 && pitch != 0) {
> if (scp != scp->sc->cur_scp)
> pitch *= 2;
> sysbeep(pitch, duration);
>
> Can you verify that this fix works for you?
yes, it does
but, I think, this may produce faster code:
+} else if (duration && pitch) {
I also found couple more problems:
00.
`kbdcontrol -b 128.800`
`(sleep 2;echo -e "\x07";sleep 2)&`
If I stay on the same vty, I hear 800Hz bell, if I switch
to another vty, I hear ~400Hz bell.
`kbdcontrol -b normal`
`(sleep 2;echo -e "\x07";sleep 2)&`
If I stay on the same vty, I hear normal bell, if I switch
to another vty, I hear a bell with pitch twice as _high_.
01.
`kbdcontrol quiet.115.400` - won't set SC_QUIET_BELL flag
[0]
(http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/root/src \
/src/sys/dev/syscons/syscons.c?rev=1.399&content-type=text/plain)
22.03.2003; 23:12:44
[SorAlx] http://cydem.org.ua/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Love from abroad
Hi, Elfriede here, A nice lady wants to correspond with you. check her out Let me know and I won't write you again. Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Binary Security Updates
Ok, I've decided that my binary security updates code is now release-worthy. Right now I'm only building updates for 4.7-RELEASE; as soon as 4.8-RELEASE comes out I'll start building updates for that as well. Note that this code only works properly if you performed a binary install of the -RELEASE and have not recompiled anything (ie, haven't applied any updates since October), so theoretically nobody should be using this until after 4.8 is released. Everything is at http://www.daemonology.net/freebsd-update/ including a portified version of the client and the resulting package. MD5 hashes are dac0f4bdf3d23b642bcbbac0e544821e, 12f69c9d0a2bf1f5278e49f0a4821aa7, b96bfc6bffcbfa18130250e36e6109d6, and 227819b9403a6f727566bd6ad5a79684 for server, client, client port, and client package respectively. Feedback is welcome. ;) Colin Percival PS. This is probably of interest to people reading stable@ as well, but that would apparently constitute excessive cross-posting. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lots of kernel core dumps
On Sun, 23 Mar 2003 00:10:38 +0100 Daniela <[EMAIL PROTECTED]> wrote: > > I know, but 5.0-RELEASE was > > > > a) A work-in-progress, not a perfect, bug-free release > > > > b) A snapshot of 5.0-CURRENT > > > > You read the 5.0 Early Adopter's Guide, right? Bugs like this are > > expected at this stage in the development process, and if you > > encounter them then you need to either give up on 5.x and go back to > > 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed there. > > > > Kris > > Yes, I read the Early Adopter's Guide. > Is there any way to solve this without upgrading to -current? > I want a stable server, of course, but I still want to help the FreeBSD folks > to make 5.0 the best release ever. This requires testing to be done. > > Daniela current isn't really any less stable than 5.0 release, likely more stable... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: boot without user and password
There is also the autologin (al) option in gettytab(5) that logs in a user instead of prompting for a username/password. You can run X from his .profile btw. isn't this more appropriate for freebsd-questions instead of -hackers? On Thu, 20 Mar 2003 16:18:43 + "Emilio Manuel" <[EMAIL PROTECTED]> wrote: > I want to know how a FreeBSD box, just after finish booting process, > can start automatically a session with a predeterminate user without > doing the normal login process (ie, without typing user and password). > > I wan to do this under Xwindows because I pretend to use this box as a > "dumb X terminal" that can display messages send from another UNIX > machine. > > Security themes don't bother me, cause I use this box in a small local > > network without conflictive users. > > Thank you in advance. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Lots of kernel core dumps
On Sun, Mar 23, 2003 at 12:10:38AM +0100, Daniela wrote: > Yes, I read the Early Adopter's Guide. > Is there any way to solve this without upgrading to -current? If you wanted to dig through the CVS commit logs to find the change that fixed this problem (this may be difficult), you could back-port it, but other than that, not really. Kris pgp0.pgp Description: PGP signature
Re: Lots of kernel core dumps
> I know, but 5.0-RELEASE was > > a) A work-in-progress, not a perfect, bug-free release > > b) A snapshot of 5.0-CURRENT > > You read the 5.0 Early Adopter's Guide, right? Bugs like this are > expected at this stage in the development process, and if you > encounter them then you need to either give up on 5.x and go back to > 4.x-STABLE, or upgrade to 5.0-CURRENT if they are already fixed there. > > Kris Yes, I read the Early Adopter's Guide. Is there any way to solve this without upgrading to -current? I want a stable server, of course, but I still want to help the FreeBSD folks to make 5.0 the best release ever. This requires testing to be done. Daniela To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: ld.so and hard links
> On Sat, 2003-03-22 at 07:30, Terry Lambert wrote: > > You could potentially save a lot of memory. *However*. You may > > not want to do this, since you are defeating priviledge seperation > > that is what made you want to use jails in the first place. > > There's a Linux Jail like thing called vserver, it has a feature where > you hardlink a whole bunch of stuff for different jails (it has tools > for building a set of jails from a given tree). It does a copy on write > for any of these hardlinked files so you don't get the security issue. > > No idea if it's possible to implement something like that for a jail :) schg flag is sufficient to do impossible hardlinked files change in jail IMHO Or I forgot something? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: OID problem with Init?
In the last episode (Mar 22), Ben Burke said: > So my questions are: > 1. Does init check for this seemingly retired OID on purpose? > 2. What's "The Right Way" or even "A Right Way" to do an installworld > on a remote machine? Serial console :) Otherwise, you can just installworld in multiuser mode, and reboot after it's done. The advise to install in single-user mode is just so that people logged in while you install don't have problems due to binaries getting installed before required libraries, etc. -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
RE: jail support for ping, traceroute, etc.. crude hack
Hello, Another possibility would be to deny access to IP_FW_* and IP_DUMMYNET_* in getsockopt(), or at least limit access to the IP addresses the jail is assigned (there's a struct thread pointer in the struct sockopt that it receives, meaning we can get to ucred and the jail's struct prison pointer). This should mitigate some of the security concerns. Thanks, -- Mooneer Salem GPLTrans: http://www.translator.cx/ lifeafterking.org: http://www.lifeafterking.org/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of "."@babolo.ru Sent: Monday, March 17, 2003 2:57 AM To: Peter Jeremy Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: jail support for ping, traceroute, etc.. crude hack > On Mon, Mar 17, 2003 at 10:06:27AM +0300, "."@babolo.ru wrote: > >It is time to invent "ping socket" and "traceroute socket" > >in addition to tcp, udp, divert so on? > > Whilst this might seem nice, actually implementing so that it is > both useful and safe is not easy. > > For a "ping socket", this is reasonably easy if all you want is the > ability to send "ICMP ECHO REQUEST" packets and receive any "ICMP ECHO > REPLY" packets associated with previous request packets. It's not > totally trivial because the kernel has to keep the state for outgoing > packets to ensure that only the correct incoming packets are > forwarded. (This is a security issue - you don't want somone finding > out hosts someone outside that jail is pinging). Remember to allow > for multiple responses to a single request and for long delays. You > might also want to implement resource restrictions to prevent someone > flooding the system with request packets. Not so easy to do but easy understandable for me. > A "traceroute socket" is harder: There's no "ICMP TRACEROUTE" packet. > Instead, traceroute(8) sends outgoing IP packets with varying TTL > sizes and monitors incoming ICMP looking for check for "HOST > UNREACHABLE - TIME EXCEEDED IN TRANSIT" packets. Again, the kernel > would need to validate the incoming packets against outgoing packets. "traceroute socket" is just a curiosity. It seems to me better use UDP socket with some controls and "ping socket" from above. But way to obtain "ping socket" coupled with UDP socket is above my brain. Or may be more common way? Semiraw socket for ability send some classes of IP packets and seceive all induced ICMP ICMP ECHO REQUEST, any UDP and other protocols exept TCP with correct source IP address is probably secure enough for use by root in jail. > In both cases, you also need to work out how to handle other random > ICMP packets that be received as a result of the outgoing packets. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: misc/41772: can't disable keybell [PATCH]
> Incidentally, using quiet.off doesn't
> shut it up either which is very confusing since quiet sets
> SC_QUIET_BELL.
it does, actually
the `man kbdcontrol` doesn't say that it also checks to see
if the beeping console is not current:
if (scp != scp->sc->cur_scp && (scp->sc->flags & SC_QUIET_BELL))
> +} else if (duration != 0 && pitch != 0) {
why using "if (duration != 0 && pitch != 0)" is
better than "if (!(duration && pitch))"?
> Can you verify that this fix works for you?
OK, I'll check it after work
22.03.2003; 09:09:34
[SorAlx] http://cydem.org.ua/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: misc/41772: can't disable keybell [PATCH]
On 22-Mar-2003 [EMAIL PROTECTED] wrote:
>
>> http://www.freebsd.org/cgi/query-pr.cgi?pr=41772
> This appears to be _VERY_ old problem (I don't remember
> it on 2.2.7-RELEASE, though)
> In short: the beeper still produces noises (clicks) when
> shut up with `kbdcontrol -b off`
Using kbdcontrol -b off on my laptop running current does
turn off the sound already. On a stable machine I still
do see the problem. Incidentally, using quiet.off doesn't
shut it up either which is very confusing since quiet sets
SC_QUIET_BELL.
> (as well a this one:
> 'http://www.FreeBSD.org/cgi/query-pr.cgi?pr=kern/44257' -
> it works well for my EIDE controller).
PCI ID's for the ICH4 controllere were committed prior to 4.7.
However, thanks for your submission.
> FreeBSD 4.6.2-RELEASE:
> ===8<===
> --- ./syscons.c.ORIG Fri Mar 21 23:10:05 2003
> +++ ./syscons.c Fri Mar 21 23:10:37 2003
> @@ -3385,6 +3385,9 @@
> if (scp != scp->sc->cur_scp && (scp->sc->flags & SC_QUIET_BELL))
> return;
>
> +if (!(duration && pitch))
> + return;
> +
> if (scp->sc->flags & SC_VISUAL_BELL) {
> if (scp->sc->blink_in_progress)
> return;
> ===8<===
This patch would inadvertently turn off visual bell's if you
set the duration or pitch to zero manually. A better patch
might be:
Index: syscons.c
===
RCS file: /usr/cvs/src/sys/dev/syscons/syscons.c,v
retrieving revision 1.399
diff -u -r1.399 syscons.c
--- syscons.c 3 Mar 2003 16:24:44 - 1.399
+++ syscons.c 22 Mar 2003 14:38:58 -
@@ -3547,7 +3547,7 @@
if (scp != scp->sc->cur_scp)
scp->sc->blink_in_progress += 2;
blink_screen(scp->sc->cur_scp);
-} else {
+} else if (duration != 0 && pitch != 0) {
if (scp != scp->sc->cur_scp)
pitch *= 2;
sysbeep(pitch, duration);
Can you verify that this fix works for you?
--
John Baldwin <[EMAIL PROTECTED]> <>< http://www.FreeBSD.org/~jhb/
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
OID problem with Init?
Hello Everyone,
I was looking for a good way to run "make installworld" in single-user
mode on a machine which I don't have any kind of remote hands or
serial-console access to. The first thought that came to my head was to
temporarily put the commands at the end of rc.shutdown. I'm not sure if
the machine is still multi-user at that point. Anyway it worked, but on
such a slow machine it didn't complete before init timed out the
shutdown script. So I looked at init...
On line 1576 (spacing changed, comment added for email):
if (
sysctlbyname("kern.shutdown_timeout", &shutdowntimeout, &len, NULL, 0)
== -1 || shutdowntimeout < 2
) shutdowntimeout = DEATH_SCRIPT; /* DEATH_SCRIPT = 120 */
I know that there was a "kern.shutdown_timeout" in FBSD 3, but there
doesn't seem to be one now in FBSD 4.8-RC (from yesterday).
So my questions are:
1. Does init check for this seemingly retired OID on purpose?
2. What's "The Right Way" or even "A Right Way" to do an installworld
on a remote machine?
Thanks in advance!
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
