Re: Idea for FreeBSD
On Thu, Aug 07, 2008 at 01:06:38AM -0400, Mike Meyer wrote:
>On Wed, 6 Aug 2008 22:34:51 "Michael B Allen" <[EMAIL PROTECTED]> wrote:
> > But of course the format of data in a database is largely irrelevant.
> > You could implement the same thing with dbm files or a more forgiving
> > text format.
>
> Right. For that matter, you could leave the data in shell scripts, and
> build a layer of meta information and tools to manipulate these things
> - which is similar to what I see in Linux distros.
>
> The Solaris smf tools provide some nice facilities: one is single
> interface to start, stop, check and restart all the services on a
> system. We pretty much have that, as they all use the same basic
> arguments to their rc scripts. The only issue is figuring out which
> directory to find the rc script in.
I use for this simple script [1] plus some programmable completion.
>
> The other is a single interface to enable, disable and query the
> status of all the services. All we really have is the last one: you
> can run the script with the rcvar argument, and it'll list the
> appropriate variable if it's set, and the value it's set
> to. Maybe. Not all of them support this yet.
> > As for getting rid of rc.d scripts, yes they're decrepit and I would
> > love to see them go but they're simple and third party software may
> > depend on them being the norm.
Can You please be more elaborate? Yes, rc.d scripts have some problems,
but I don't think We need to get rid of them.
[1]:
$cat /usr/local/bin/service
#!/bin/sh
name=$1
cmd=$2
. /etc/rc.subr
if [ -z "${name}" -o -z "${cmd}" ]
then
echo ${0##*/} service_name command
exit 3
fi
if [ -r "/etc/rc.d/${name}" ]
then
run_rc_script "/etc/rc.d/${name}" ${cmd}
exit 0
fi
if [ -r "/usr/local/etc/rc.d/${name}" ]
then
run_rc_script "/usr/local/etc/rc.d/${name}" ${cmd}
exit 0
fi
if [ -r "/usr/local/etc/rc.d/${name}.sh" ]
then
run_rc_script "/usr/local/etc/rc.d/${name}.sh" ${cmd}
exit 0
fi
echo "service '${name}' not found"
exit 2
--
Adios
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB key && kernel: da0: Attempt to query device size failed: UNIT ?ATTENTION, Medium not present
El día Wednesday, August 06, 2008 a las 07:29:31PM +0200, Oliver Fromme escribió: > Matthias Apitz wrote: > > I've updated usb/80361, see > > http://www.freebsd.org/cgi/query-pr.cgi?pr=80361 > > because I have the same problem as well that an USB key attaches fine > > when plugged in at boot time, but not later: > > I'm just wondering what happens if you enforce a rescan > on the (virtual) SCSI bus. That is, after you have > plugged in the USB stick and the problem occured, type > "camcontrol rescan 0". > this did not helped; I tried it a lot of times; also reading with dd(1) from /dev/da0 did not helped; > If that doesn't help, please try this patch: ... The problem is that this was a USB stick of a friend of me in which I have created a booting FreeBSD so he can make the installation of it in an eeePC; will try to get back this USB stick from him for further tests... matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e <[EMAIL PROTECTED]> - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ We should all learn from the peoples of The Netherlands, France and Ireland. Aprendamos todos de los pueblos de Holanda, Francia e Irlanda. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: > To who it may concern, > >I am A FreeBSD administrator as well as a Solaris Administrator. I use > BSD at home but Solaris at work. I love both OS's but I would like to > increase the administrative capability of FreeBSD. > >In Solaris 10 the Services Management Facility (SMF) was introduced. > Basically what it does, is take all the rc.d scripts and puts them into > a database to manage. Everything is converted to XML and two basic > commands (svcs and svcadm) are used to manage everything. I highly recommend you and anyone advocating the use of XML for such things read the following whitepaper/study, in full: http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: consolekit on 7.0-STABLE i386
Kostik Belousov wrote: On Fri, Aug 01, 2008 at 06:16:49PM +0400, sam wrote: Nate Eldredge wrote: On Wed, 30 Jul 2008, sam wrote: 0 19 0 1113M29M 112 0 0 032 0 0 1 100 5549 1682 11 1 88 0 19 0 1113M29M 297 0 0 0 136 0 0 2 122 78880 1749 6 7 87 | consolekit in |waitvt state, influencing on high volumes in procs-b I don't understand what the problem is. It looks like consolekit is sleeping and not using any CPU. "waitvt" just indicates where in the kernel it's sleeping. I don't understand what you mean by "high volumes in procs-b". How-To-Repeat: -- # (|cd /usr/ports/sysutils/consolekit/ && make install clean) # /usr/local/etc/rc.d/dbus forcestart # vmstat -w 1 procs memory page disk faults cpu r b w avmfre flt re pi pofr sr ad0 in sy cs us sy id 2 1 0 62252K 644M88 0 0 080 0 02 83 279 1 1 98 0 1 0 62252K 644M 0 0 0 0 0 0 04 134 292 0 3 97 0 1 0 62252K 644M 0 0 0 0 0 0 04 123 299 0 2 98 1 1 0 62252K 644M 0 0 0 0 0 0 03 120 305 0 3 97 ^C # /usr/local/sbin/console-kit-daemon && vmstat -w 1 procs memory page disk faults cpu r b w avmfre flt re pi pofr sr ad0 in sy cs us sy id 2 1 0 67572K 643M88 0 0 080 0 02 83 279 1 1 98 0 16 0 68660K 643M 103 0 0 0 2 0 10 13 643 381 2 4 94 0 16 0 68660K 643M 0 0 0 0 0 0 03 120 281 0 4 96 0 16 0 68660K 643M 0 0 0 0 0 0 02 120 278 0 3 97 0 16 0 68660K 643M 0 0 0 012 0 28 34 120 385 0 3 97 0 16 0 68660K 643M 0 0 0 0 0 0 04 120 292 0 3 97 ^C # |-- please, any solution ... Solution for what ? There is nothing wrong with the system. For the purely estetisk purpose, you may look up the line tsleep(VTY_WCHAN(sc, i), PZERO | PCATCH, "waitvt", 0); or similar in sys/dev/syscons/syscons.c, and remove the "PZERO |" substring from it. ok Why proc-b on the HEAD, have low values (with working consolekit)? /Vladimir Ermakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB key && kernel: da0: Attempt to query device size failed: UNIT ?ATTENTION, Medium not present
Matthias Apitz wrote: > Oliver Fromme wrote: > > Matthias Apitz wrote: > > > I've updated usb/80361, see > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=80361 > > > because I have the same problem as well that an USB key attaches fine > > > when plugged in at boot time, but not later: > > > > I'm just wondering what happens if you enforce a rescan > > on the (virtual) SCSI bus. That is, after you have > > plugged in the USB stick and the problem occured, type > > "camcontrol rescan 0". > > this did not helped; I tried it a lot of times; OK. > also reading with dd(1) from /dev/da0 did not helped; I think reading from it isn't expected to help. The device needs to be opened for _writing_ so the GEOM layer assumes that the partition or slice table was modified and re-reads it from the media. Something like this should be sufficient: dd if=/dev/null of=/dev/da0 count=0 It openes the device for writing (this is important), but doesn't actually write anything to it. > > If that doesn't help, please try this patch: > ... > > The problem is that this was a USB stick of a friend of me in which I > have created a booting FreeBSD so he can make the installation of it in > an eeePC; will try to get back this USB stick from him for further > tests... OK. A little bit of background information: If a USB memory stick is detected fine during boot, but not when plugged into the running system, it usually indicates that the USB stick needs a longer delay to be ready for the CAM SCSI layer. The default delay is 200 ms. This might be too short for some USB sticks. The patch increases it to 2000 ms. If that still doesn't help, then there must be a completely different problem with your USB stick. In that case someone with more intimate knowledge of the USB code needs to help. Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd cat man du : where Unix geeks go when they die ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
I wonder opinions on more general question: Does somebody believe in necessity of separate infrastructure for daemons(services)? As for me i very dislike unclean of "what where located". Some configuration lie in /etc, some in /usr/local/etc, some in /usr/local/program_name. In addition there is own inclusions in program conf's of some vital data/parameters located somewhere, not to mention program binary, libraries and startup scripts. What the shortest dump command that allow after fresh installation restore full functionality? So, i believe that clean rule of daemons(services) arrangement in system more important than startup design. May be rule that "all daemons should nest in /svc" can help. For example, /svc -mostly read /svc/daemon_name - daemon dir /svc/daemon_name/bin/ - program itself /svc/daemon_name/*.conf - configuration /svc/daemon_name/data/ - data itself (mostly read, rarely write) + symlinks to real data /svc/daemon_name/var2/*.conf - another configuration named var2 (for another instance) /svc/daemon_name/var2/data/ - data itself (mostly read, rarely write) + symlinks to real data another configuration named var2 /svc/daemon_name/cs/ - control scripts (startup/shutdown etc) So, by design there is ability: list all daemon (readdir /svc) start / stop daemons: svc daemon_name start = (do a "/svc/daemon_name/cs/start") use alternative configuration: svc daemon_name var2 start = (do a "/svc/daemon_name/cs/start -c var2") dump all functionallity dump /svc Thursday, August 07, 2008, 3:14:51 AM, you wrote: wfc> To who it may concern, wfc>I am A FreeBSD administrator as well as a Solaris Administrator. I use wfc> BSD at home but Solaris at work. I love both OS's but I would like to wfc> increase the administrative capability of FreeBSD. wfc>In Solaris 10 the Services Management Facility (SMF) was introduced. wfc> Basically what it does, is take all the rc.d scripts and puts them into wfc> a database to manage. Everything is converted to XML and two basic wfc> commands (svcs and svcadm) are used to manage everything. wfc>I would like to submit the idea of implementing a similar environment wfc> into FreeBSD. After looking through the developers links and googling I wfc> found no project for FreeBSD that implemented anything similar to this. wfc> I have included a link below to give a better understanding of SMF and wfc> its capabilities. wfc>Is it possible, if it does not exist already, to look at the wfc> possibility of implementing the concept of SMF into FreeBSD? I would wfc> gladly be an active supporter in this endeavor. wfc> Will Bentley wfc> Future CIS wfc> 410-782-5954 wfc> "Your resource for computer expertise!" wfc> ___ wfc> freebsd-hackers@freebsd.org mailing list wfc> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers wfc> To unsubscribe, send any mail to "[EMAIL PROTECTED]" -- Best regards, Anthonymailto:[EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
Am 07.08.2008 um 08:31 schrieb Michael B Allen: mean the whole Unix runlevel rc.d apparatus in general is decrepit. Hi, Jordan! 8-) There should be a library to install, start, stop, restart, uninstall, disable, enable, change order of services and also change the runlevel. And then there should be a very small utility that calls the library to invoke the desired operations from the commandline and from init. As I'm having my daily struggles with launchd on Mac OS Servers (subsystems like lpd being turned of by mechanisms unknown to me, orphaned processes being unceremoniously eaten by launchd without any good reasons) the dream of having one tool instead of init, cron, inetd and the rest of that gang has turned into more work. As I'm also have an allergy against AIX since I came into contact with SMIT for the first time: Be careful what you're asking for, you might really get it. If the library and corresponding utility are implemented correctly, the format of the file containing service state should be moot since no one will ever look at it Besides in emergencies. That's also the time where the tools you would urgently need to repair something aren't working because the system isn't completely up and running. Believe me: Editing XML using ed isn't that exciting. (which is to say dbm or some other binary-blob format should be used since it makes programming the said library much cleaner). Who cares for the programmer? 8-) But I just made that up. Of course such things are never as simple as they sound the first time around. It's worse. Things that are looking great on paper often turn out to be a nightmare when you have to deal with it. And things like "I still intend on writing a plist format (the non-XML one) parser to incorporate into the code base [...]" on http://wiki.freebsd.org/launchd are scaring me even more (the only thing that makes .plists in binary format bearable is the fact that they can be transformed into XML and dealt with reasonable tools). Achim
Re: Idea for FreeBSD
Jeremy Chadwick wrote: On Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: To who it may concern, I am A FreeBSD administrator as well as a Solaris Administrator. I use BSD at home but Solaris at work. I love both OS's but I would like to increase the administrative capability of FreeBSD. In Solaris 10 the Services Management Facility (SMF) was introduced. Basically what it does, is take all the rc.d scripts and puts them into a database to manage. Everything is converted to XML and two basic commands (svcs and svcadm) are used to manage everything. I highly recommend you and anyone advocating the use of XML for such things read the following whitepaper/study, in full: http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf Heh. Loved all the little asides to Nancy... Amazing it hasn't been fixed in 4 years. Anyhow, yes: ASN.1 is smaller, and hence faster than XML for networked applications. Which is fine, but as far as I can see doesn't address the question at hand. There are two connected questions here: * What technology should be used to implement the FreeBSD rc.subr system? * What functionality could or should be added to the FreeBSD rc.subr system? Where the answer to the first question clearly constrains the results of the second. So what are the requirements for the rc system? Off the top of my head -- and I've probably missed some vital considerations here -- in order of priority: 1 reliability. The system has to boot up. 2 repeatability. The system has to boot up in a consistent state 3 fault tolerance. The system cannot fail to boot up unless the problems really are terminal. 4 configurability. The system has to boot up correctly for all conceivable combinations of hardware and software. 5 portability. Should run on anything from the smallest of embedded devices to the most enormous high power super computers to the most transient of virtualized hosts. 6 manageability. Must be comprehensible by ordinary mortals. 7 efficiency. Must bring the system up as fast as is practicable and without excessive use of system resources What does XML-based technology bring to this? As the OP states the primary benefit is in manageability. I would contend that the advantage claimed here is rather less significant than indicated. We already have a central database of configuration information -- /etc/rc.conf -- and while we don't have one single application to control starting and stopping services we have the next best thing: a consistent user interface for calling the individual rc-scripts. Indeed, as other posters have shown elsewhere in this thread, adding that sort of functionality is only a Small Matter of Programming using the existing tools. What's wrong wwith using XML? XML adds significantly to the complexity of an rc system -- it's suddenly necessary to have another shlib or two and several compiled applications available early in the boot process. XML itself is too general-purpose: it has too much baggage designed for its primary function of facilitating interoperation between diverse systems in different zones of control, none of which is particularly applicable to system startup. I can see the attraction of writing a nice pointy-clicky database-backed GUI management interface to encourage the uninitiated administrator, but that can only be an adjunct to the current setup, not a replacement. If you can't fix a broken system via a text only serial console accessed across whatever sort of low-bandwidth emergency connectivity you could imagine, then I suspect quite strongly it's not going to receive wholehearted community approval. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard Flat 3 PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate Kent, CT11 9PW signature.asc Description: OpenPGP digital signature
Re: consolekit on 7.0-STABLE i386
On Thu, Aug 07, 2008 at 12:00:37PM +0400, sam wrote: > Kostik Belousov wrote: > >On Fri, Aug 01, 2008 at 06:16:49PM +0400, sam wrote: > > > >>Nate Eldredge wrote: > >> > >>>On Wed, 30 Jul 2008, sam wrote: > >>> > >>> > 0 19 0 1113M29M 112 0 0 032 0 0 1 100 5549 > 1682 11 1 88 > 0 19 0 1113M29M 297 0 0 0 136 0 0 2 122 78880 > 1749 6 7 87 > | > > consolekit in |waitvt state, influencing on high volumes in procs-b > > >>>I don't understand what the problem is. It looks like consolekit is > >>>sleeping and not using any CPU. "waitvt" just indicates where in the > >>>kernel it's sleeping. I don't understand what you mean by "high > >>>volumes in procs-b". > >>> > >>> > >>How-To-Repeat: > >>-- > >># (|cd /usr/ports/sysutils/consolekit/ && make install clean) > >> > >># /usr/local/etc/rc.d/dbus forcestart > >> > >># vmstat -w 1 > >>procs memory page disk faults cpu > >>r b w avmfre flt re pi pofr sr ad0 in sy cs us > >>sy id > >>2 1 0 62252K 644M88 0 0 080 0 02 83 279 1 > >>1 98 > >>0 1 0 62252K 644M 0 0 0 0 0 0 04 134 292 0 > >>3 97 > >>0 1 0 62252K 644M 0 0 0 0 0 0 04 123 299 0 > >>2 98 > >>1 1 0 62252K 644M 0 0 0 0 0 0 03 120 305 0 > >>3 97 > >>^C > >># /usr/local/sbin/console-kit-daemon && vmstat -w 1 > >>procs memory page disk faults cpu > >>r b w avmfre flt re pi pofr sr ad0 in sy cs us > >>sy id > >>2 1 0 67572K 643M88 0 0 080 0 02 83 279 1 > >>1 98 > >>0 16 0 68660K 643M 103 0 0 0 2 0 10 13 643 381 > >>2 4 94 > >>0 16 0 68660K 643M 0 0 0 0 0 0 03 120 281 > >>0 4 96 > >>0 16 0 68660K 643M 0 0 0 0 0 0 02 120 278 > >>0 3 97 > >>0 16 0 68660K 643M 0 0 0 012 0 28 34 120 385 > >>0 3 97 > >>0 16 0 68660K 643M 0 0 0 0 0 0 04 120 292 > >>0 3 97 > >>^C > >># > >>|-- > >> > >>please, any solution ... > >> > > > >Solution for what ? There is nothing wrong with the system. > > > >For the purely estetisk purpose, you may look up the line > > tsleep(VTY_WCHAN(sc, i), PZERO | PCATCH, "waitvt", 0); > >or similar in sys/dev/syscons/syscons.c, and remove the "PZERO |" substring > >from it. > > > ok > > Why proc-b on the HEAD, have low values (with working consolekit)? On what revision of HEAD ? I committed the change that causes the thread to sleep on the PZERO+1 priority instead of PZERO as r181286. pgp9mt9NKQk2X.pgp Description: PGP signature
Re: consolekit on 7.0-STABLE i386
Kostik Belousov wrote: On Thu, Aug 07, 2008 at 12:00:37PM +0400, sam wrote: Kostik Belousov wrote: On Fri, Aug 01, 2008 at 06:16:49PM +0400, sam wrote: Nate Eldredge wrote: 0 3 97 0 16 0 68660K 643M 0 0 0 012 0 28 34 120 385 0 3 97 0 16 0 68660K 643M 0 0 0 0 0 0 04 120 292 0 3 97 ^C # |-- please, any solution ... Solution for what ? There is nothing wrong with the system. For the purely estetisk purpose, you may look up the line tsleep(VTY_WCHAN(sc, i), PZERO | PCATCH, "waitvt", 0); or similar in sys/dev/syscons/syscons.c, and remove the "PZERO |" substring >from it. ok Why proc-b on the HEAD, have low values (with working consolekit)? On what revision of HEAD ? I committed the change that causes the thread to sleep on the PZERO+1 priority instead of PZERO as r181286. - # uname -a FreeBSD 8.0-CURRENT FreeBSD 8.0-CURRENT #3: Fri Jul 4 20:01:51 MSD 2008 root@:/usr/obj/usr/src/sys/DAMASK i386 - /Vladimir Ermakov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Suggestion for 'pkg_add -r'
Hi, In my pkg_improved GSoC project I've added a nice feature for 'pkg_add -r' which displays the size of the file being downloaded as well as progress status in % and bytes/kb/mb/... and download speed. If someone could test it and comment it would be perfect, below you can find the patches for RELENG_7 and -CURRENT. (As for now pkg_add does not have a -q/Q option (quiet), but this could perhaps be used to deprecate the output?). RELENG_7: http://home.no.net/andenore/patches/pkg_install_2008-08-06_RELENG_7.diff CURRENT: http://home.no.net/andenore/patches/pkg_install_2008-08-06_CURRENT.diff Thanks, Anders Nore ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB key && kernel: da0: Attempt to query device size failed: UNIT ?ATTENTION, Medium not present
On Thu, Aug 07, 2008 at 09:54:53AM +0200, Matthias Apitz wrote: > El día Wednesday, August 06, 2008 a las 07:29:31PM +0200, Oliver Fromme > escribió: > > > Matthias Apitz wrote: > > > I've updated usb/80361, see > > > http://www.freebsd.org/cgi/query-pr.cgi?pr=80361 > > > because I have the same problem as well that an USB key attaches fine > > > when plugged in at boot time, but not later: > > > > I'm just wondering what happens if you enforce a rescan > > on the (virtual) SCSI bus. That is, after you have > > plugged in the USB stick and the problem occured, type > > "camcontrol rescan 0". > > > > this did not helped; I tried it a lot of times; also reading with dd(1) > from /dev/da0 did not helped; > > > If that doesn't help, please try this patch: > ... > > The problem is that this was a USB stick of a friend of me in which I > have created a booting FreeBSD so he can make the installation of it in > an eeePC; will try to get back this USB stick from him for further > tests... Can we get the brand and model of USB stick, and any specific model/version numbers that are on the device? The dmesg you provided doesn't have very good vendor strings in it (that's not your fault). I can tell you that in the case of *some* SanDisk USB sticks (and despite this, I still buy/use their products -- I like them), there are versions with buggy USB code on them. I spent quite some time with Supermicro trying to find out why a SanDisk USB stick would not boot on some of their servers -- it turned out to be broken/buggy firmware code inside of the USB stick itself. Replacing it with a different version (same size/model though) fixed the issue. Just something to be aware of... -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB key && kernel: da0: Attempt to query device size failed: UNIT ?ATTENTION, Medium not present
El día Thursday, August 07, 2008 a las 04:18:19AM -0700, Jeremy Chadwick escribió: > Can we get the brand and model of USB stick, and any specific > model/version numbers that are on the device? The dmesg you provided > doesn't have very good vendor strings in it (that's not your fault). ... here we go: Aug 6 10:06:12 rebelion kernel: umass0: on uhub4 Aug 6 10:06:12 rebelion root: Unknown USB device: vendor 0x08ec product 0x0020 bus uhub4 Aug 6 10:06:12 rebelion kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug 6 10:06:12 rebelion kernel: da0: Removable Direct Access SCSI-0 device Aug 6 10:06:12 rebelion kernel: da0: 40.000MB/s transfers Aug 6 10:06:12 rebelion kernel: da0: Attempt to query device size failed: UNIT ATTENTION, Medium not present seems to be this one: http://luhdc.berlios.de/Pages/USB//ViewSingle/ID=143/ matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e <[EMAIL PROTECTED]> - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ We should all learn from the peoples of The Netherlands, France and Ireland. Aprendamos todos de los pueblos de Holanda, Francia e Irlanda. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
"Michael B Allen" <[EMAIL PROTECTED]> writes: > I did not mean to say that the scripts themselves were decrepit. I > mean the whole Unix runlevel rc.d apparatus in general is decrepit. FreeBSD doesn't have runlevels. Solaris does. You don't like runlevels, but you want FreeBSD to be more like Solaris. Make up your mind... DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On 2008-Aug-06 19:14:51 -0400, [EMAIL PROTECTED] wrote: > In Solaris 10 the Services Management Facility (SMF) was introduced. The main purpose of SMF appears to be to drum up business for Sun's training courses by radically changing Sol10 Administration for little benefit. >Basically what it does, is take all the rc.d scripts and puts them into >a database to manage. Everything is converted to XML and two basic >commands (svcs and svcadm) are used to manage everything. So you take each line from inetd.conf (literally) and wrap it in several KB of XML. This definitely adds to bloat and doesn't even obey the spirit of XML (since the content of each inetd.conf entry remains opaque). I haven't looked at what happens to /etc/inittab or the rc.d scripts but I expect that it's similar. It's not clear what benefit this brings. The svcs and svcadm commands are among the most arcane I have bumped into during my >20 years of administering Unix. I agree that some of the process management facilities of SMF are better than exists for most FreeBSD daemons but don't believe that all the other baggage is worth the improvement. With FreeBSD, I can configure virtually all the system via a single text file - which is easily found and kepy under configuration control. With Sol10, there are random bits of configuration spread all over the system and there is no obvious way to control configuration. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpXrc0UnsFtr.pgp Description: PGP signature
Re: USB key && kernel: da0: ...
> Matthias Apitz wrote: > Aug 6 10:06:12 rebelion kernel: umass0: 2.00/2.00, addr 2> on uhub4 > Aug 6 10:06:12 rebelion root: Unknown USB device: vendor 0x08ec product > 0x0020 bus uhub4 > Aug 6 10:06:12 rebelion kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug > 6 10:06:12 > rebelion kernel: da0: Removable Direct Access SCSI-0 > device > Aug 6 10:06:12 rebelion kernel: da0: 40.000MB/s transfers > Aug 6 10:06:12 rebelion kernel: da0: Attempt to query device size failed: > UNIT ATTENTION, Medium not present > Here is another example: Aug 5 14:48:59 niobe kernel: umass0: on uhub3 Aug 5 14:48:59 niobe root: Unknown USB device: vendor 0x0951 product 0x1603 bus uhub3 Aug 5 14:48:59 niobe kernel: da1 at umass-sim0 bus 0 target 0 lun 0 Aug 5 14:48:59 niobe kernel: da1: Removable Direct Access SCSI-2 device Aug 5 14:48:59 niobe kernel: da1: 40.000MB/s transfers Aug 5 14:48:59 niobe kernel: da1: 1905MB (3902464 512 byte sectors: 255H 63S/T 242C) Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR Aug 5 14:55:57 niobe kernel: umass0: at uhub3 port 5 (addr 2) disconnected Aug 5 14:55:57 niobe kernel: (da1:umass-sim0:0:0:0): lost device Aug 5 14:55:57 niobe kernel: (da1:umass-sim0:0:0:0): removing device entry Aug 5 14:55:57 niobe kernel: umass0: detached Needless to say, this stick works perfectly OK under Windows and Linux. -- Michel TALON ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggestion for 'pkg_add -r'
On 7 Aug 2008, at 11:53, Anders Nore wrote: Hi, In my pkg_improved GSoC project I've added a nice feature for 'pkg_add -r' which displays the size of the file being downloaded as well as progress status in % and bytes/kb/mb/... and download speed. If someone could test it and comment it would be perfect, below you can find the patches for RELENG_7 and -CURRENT. (As for now pkg_add does not have a -q/Q option (quiet), but this could perhaps be used to deprecate the output?). RELENG_7: http://home.no.net/andenore/patches/pkg_install_2008-08-06_RELENG_7.diff CURRENT: http://home.no.net/andenore/patches/ pkg_install_2008-08-06_CURRENT.diff Some comments: * I think you have reversed the patch. :-) * Build errors: cc1: warnings being treated as errors file.c:433: warning: no previous prototype for 'power' file.c:452: warning: no previous prototype for 'human_readable' file.c:474: warning: no previous prototype for 'printHumanReadable' file.c: In function 'printHumanReadable': file.c:482: warning: comparison between signed and unsigned parallels# ./pkg_add -r joe Fetching 321.2 kB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/Latest/joe.tbz ... Downloading: 100% 321.2 kB at 214.8 kB/ s Done Fetching 2.4 MB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/All/gettext-0.17_1.tbz ... Done Fetching 2.2 MB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/All/aspell-0.60.6_2.tbz ... Downloading: 201%4.5 MB at 149.5 kB/s Something's wrong :-) Also, may I suggest that you make your output similar to fetch(1) ? Keep up the good work, -- Rui Paulo ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
Peter Jeremy <[EMAIL PROTECTED]> writes: > So you take each line from inetd.conf (literally) and wrap it in > several KB of XML. This definitely adds to bloat and doesn't even > obey the spirit of XML (since the content of each inetd.conf entry > remains opaque). s/inetd/rc/g I completely agree with you - but I also agree with whoever it was that suggested adding enable / disable commands to rc.subr. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB key && kernel: da0: ...
El día Thursday, August 07, 2008 a las 02:01:22PM +0200, Michel Talon escribió: > > Matthias Apitz wrote: > > Aug 6 10:06:12 rebelion kernel: umass0: > rev 2.00/2.00, addr 2> on uhub4 > > Aug 6 10:06:12 rebelion root: Unknown USB device: vendor 0x08ec product > > 0x0020 bus uhub4 > > Aug 6 10:06:12 rebelion kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug > > 6 10:06:12 > > rebelion kernel: da0: Removable Direct Access SCSI-0 > > device > > Aug 6 10:06:12 rebelion kernel: da0: 40.000MB/s transfers > > Aug 6 10:06:12 rebelion kernel: da0: Attempt to query device size failed: > > UNIT ATTENTION, Medium not present > > > > Here is another example: > > Aug 5 14:48:59 niobe kernel: umass0: rev 2.00/2.00, addr 2> on uhub3 > Aug 5 14:48:59 niobe root: Unknown USB device: vendor 0x0951 product 0x1603 > bus uhub3 > Aug 5 14:48:59 niobe kernel: da1 at umass-sim0 bus 0 target 0 lun 0 > Aug 5 14:48:59 niobe kernel: da1: Removable > Direct Access SCSI-2 device > Aug 5 14:48:59 niobe kernel: da1: 40.000MB/s transfers > Aug 5 14:48:59 niobe kernel: da1: 1905MB (3902464 512 byte sectors: 255H > 63S/T 242C) > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR ... Have you plug'ed in or out while writing to da1 another device in the USB? I saw this as well with a USB key which worked normaly until I did a plug'in/out on the bus; matthias -- Matthias Apitz Manager Technical Support - OCLC GmbH Gruenwalder Weg 28g - 82041 Oberhaching - Germany t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e <[EMAIL PROTECTED]> - w http://www.oclc.org/ http://www.UnixArea.de/ b http://gurucubano.blogspot.com/ We should all learn from the peoples of The Netherlands, France and Ireland. Aprendamos todos de los pueblos de Holanda, Francia e Irlanda. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB key && kernel: da0: ...
On Thu, Aug 07, 2008 at 02:01:22PM +0200, Michel Talon wrote: > > Matthias Apitz wrote: > > Aug 6 10:06:12 rebelion kernel: umass0: > rev 2.00/2.00, addr 2> on uhub4 > > Aug 6 10:06:12 rebelion root: Unknown USB device: vendor 0x08ec product > > 0x0020 bus uhub4 > > Aug 6 10:06:12 rebelion kernel: da0 at umass-sim0 bus 0 target 0 lun 0 Aug > > 6 10:06:12 > > rebelion kernel: da0: Removable Direct Access SCSI-0 > > device > > Aug 6 10:06:12 rebelion kernel: da0: 40.000MB/s transfers > > Aug 6 10:06:12 rebelion kernel: da0: Attempt to query device size failed: > > UNIT ATTENTION, Medium not present > > Here is another example: > > Aug 5 14:48:59 niobe kernel: umass0: rev 2.00/2.00, addr 2> on uhub3 > Aug 5 14:48:59 niobe root: Unknown USB device: vendor 0x0951 product 0x1603 > bus uhub3 > Aug 5 14:48:59 niobe kernel: da1 at umass-sim0 bus 0 target 0 lun 0 > Aug 5 14:48:59 niobe kernel: da1: Removable > Direct Access SCSI-2 device > Aug 5 14:48:59 niobe kernel: da1: 40.000MB/s transfers > Aug 5 14:48:59 niobe kernel: da1: 1905MB (3902464 512 byte sectors: 255H > 63S/T 242C) > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, IOERROR > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, IOERROR > Aug 5 14:55:57 niobe kernel: umass0: at uhub3 port 5 (addr 2) disconnected > Aug 5 14:55:57 niobe kernel: (da1:umass-sim0:0:0:0): lost device > Aug 5 14:55:57 niobe kernel: (da1:umass-sim0:0:0:0): removing device entry > Aug 5 14:55:57 niobe kernel: umass0: detached > > Needless to say, this stick works perfectly OK under Windows and Linux. I have the 4GB model of this USB stick/drive. I'll give it a try on my FreeBSD RELENG_7 box when I get home in about an hour. If I can reproduce the issue, I will be more than happy to send it to someone who wants to debug it (and they can keep it as my way of saying thanks). -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB key && kernel: da0: ...
Matthias Apitz wrote: > Have you plug'ed in or out while writing to da1 another device in the > USB? I saw this as well with a USB key which worked normaly until I did > a plug'in/out on the bus; No, i did not touch to the usb bus. I tried to use the stick on several FreeBSD machines, without any success. One of them paniced. I had to reboot to Windows to read the stick and then download it from here for FreeBSD :-( -- Michel TALON ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggestion for 'pkg_add -r'
RELENG_7: http://home.no.net/andenore/patches/pkg_install_2008-08-06_RELENG_7.diff CURRENT: http://home.no.net/andenore/patches/pkg_install_2008-08-06_CURRENT.diff Some comments: * I think you have reversed the patch. :-) * Build errors: cc1: warnings being treated as errors file.c:433: warning: no previous prototype for 'power' file.c:452: warning: no previous prototype for 'human_readable' file.c:474: warning: no previous prototype for 'printHumanReadable' file.c: In function 'printHumanReadable': file.c:482: warning: comparison between signed and unsigned parallels# ./pkg_add -r joe Fetching 321.2 kB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/Latest/joe.tbz ... Downloading: 100% 321.2 kB at 214.8 kB/s Done Fetching 2.4 MB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/All/gettext-0.17_1.tbz ... Done Fetching 2.2 MB from ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/All/aspell-0.60.6_2.tbz ... Downloading: 201%4.5 MB at 149.5 kB/s Something's wrong :-) Heh, yes. It's my first patch(es), so it didn't go as well as I had hoped, I believe they are fixed now. The numbers for percentage should also be corrected :-) Also, may I suggest that you make your output similar to fetch(1) ? Yes, I will work on making it similar Thanks, Anders Nore ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB key && kernel: da0: ...
On Thu, Aug 07, 2008 at 05:50:45AM -0700, Jeremy Chadwick wrote: > On Thu, Aug 07, 2008 at 02:01:22PM +0200, Michel Talon wrote: > > > Matthias Apitz wrote: > > > Aug 6 10:06:12 rebelion kernel: umass0: > > rev 2.00/2.00, addr 2> on uhub4 > > > Aug 6 10:06:12 rebelion root: Unknown USB device: vendor 0x08ec product > > > 0x0020 bus uhub4 > > > Aug 6 10:06:12 rebelion kernel: da0 at umass-sim0 bus 0 target 0 lun 0 > > > Aug 6 10:06:12 > > > rebelion kernel: da0: Removable Direct Access > > > SCSI-0 device > > > Aug 6 10:06:12 rebelion kernel: da0: 40.000MB/s transfers > > > Aug 6 10:06:12 rebelion kernel: da0: Attempt to query device size > > > failed: UNIT ATTENTION, Medium not present > > > > Here is another example: > > > > Aug 5 14:48:59 niobe kernel: umass0: > 0/0, rev 2.00/2.00, addr 2> on uhub3 > > Aug 5 14:48:59 niobe root: Unknown USB device: vendor 0x0951 product > > 0x1603 bus uhub3 > > Aug 5 14:48:59 niobe kernel: da1 at umass-sim0 bus 0 target 0 lun 0 > > Aug 5 14:48:59 niobe kernel: da1: > > Removable Direct Access SCSI-2 device > > Aug 5 14:48:59 niobe kernel: da1: 40.000MB/s transfers > > Aug 5 14:48:59 niobe kernel: da1: 1905MB (3902464 512 byte sectors: 255H > > 63S/T 242C) > > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB reset failed, IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-in clear stall failed, > > IOERROR > > Aug 5 14:49:25 niobe kernel: umass0: BBB bulk-out clear stall failed, > > IOERROR > > Aug 5 14:55:57 niobe kernel: umass0: at uhub3 port 5 (addr 2) disconnected > > Aug 5 14:55:57 niobe kernel: (da1:umass-sim0:0:0:0): lost device > > Aug 5 14:55:57 niobe kernel: (da1:umass-sim0:0:0:0): removing device entry > > Aug 5 14:55:57 niobe kernel: umass0: detached > > > > Needless to say, this stick works perfectly OK under Windows and Linux. > > I have the 4GB model of this USB stick/drive. I'll give it a try on my > FreeBSD RELENG_7 box when I get home in about an hour. > > If I can reproduce the issue, I will be more than happy to send it to > someone who wants to debug it (and they can keep it as my way of saying > thanks). As promised, when I got home I inserted the Kingston I have. I should note this disk was formatted as FAT32 on a Windows machine, and was also made bootable via a Windows utility made by Hewlett Packard. This is what I got upon inserting the device: umass0: on uhub4 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Removable Direct Access SCSI-2 device da0: 40.000MB/s transfers da0: 3836MB (7856128 512 byte sectors: 255H 63S/T 489C) GEOM_LABEL: Label for provider da0s1 is msdosfs/KINGSTON. icarus# camcontrol devlist at scbus0 target 0 lun 0 (da0,pass0) icarus# camcontrol inquiry da0 pass0: Removable Direct Access SCSI-2 device pass0: Serial Number 40.000MB/s transfers icarus# mount_msdosfs /dev/da0s1 /mnt icarus# df -k /mnt Filesystem 1024-blocks Used Avail Capacity Mounted on /dev/da0s1 3920364 12 3920352 0%/mnt This looks correct (there is no data on the FAT32 filesystem). icarus# umount /mnt icarus# I then removed the stick, and got this: umass0: at uhub4 port 6 (addr 2) disconnected (da0:umass-sim0:0:0:0): lost deviceGEOM_LABEL (da0:umass-sim0:0:: 0:Label 0): msdosfs/KINGSTON removeremoving device entryd. umass0: detached Kernel messages are being printed atop one another is a known bug (it really needs to get fixed already, since increasing PRINTF_BUFR_SIZE to 256 only makes the problem slightly better), but as you can see, it worked fine. I'm thinking this may boil down to a problem with udbp(4) getting in the way, since it's responsible for the bulk (BBB) stuff. I yank udbp(4) out of my kernel because I don't see the point in including support for something I'll never use. (And are "bulk pipes" even part of the USB standard? I don't remember reading about them as part of the USB 1.0 specification, but that was a long time ago.) Here's the relevant portion of my kernel configuration: # SCSI peripherals device
Samba, Response too big for UDP, retry with TCP, Kerberos implementation on FreeBSD
//sorry for spamming to another freebsd-ports maillist. This channel is more
suitable//
Hello,
I receive a similar problem in a current configuration (FreeBSD 7.0-Release
amd64, samba-3.0.31_1) like this:
http://lists.samba.org/archive/samba/2007-July/133625.html
and most likely I assume problems both in Samba and in realization Kerberos on
FreeBSD (IMHO Samba more:)
The problem consists that during the generation phase
(libads/kerberos.c:create_local_private_krb5_conf_for_domain) of temporary file
/var/db/samba/smb_krb5/krb5.conf. is
lost the instruction for transport protocol (if they present in /etc/krb5.conf)
So, temporary workaround for this problem looks like:
1) After unsuccessful execution
$ net ads join ...
Edit a file /var/db/samba/smb_krb5/krb5.conf., having added before
server a "tcp/" (of course, only if tcp proto is necessary tcp
also it should be present in/etc/krd5.conf):
--
[realms]
= {
kdc = tcp/
...
}
--
2) Then set forbid modification on a file
chflags schg /var/db/samba/smb_krb5/krb5.conf.
3) And trying "net join " again, with ignoring of rename error
(create_local_private_krb5_conf_for_domain: rename of
/var/db/samba/smb_tmp_krb5.IQraHE to /var/db/samba/smb_krb5/krb5.conf.
failed. Errno Operation not permitted..)
Operation must end with success execution.
Question - Whether two (FreeBSD/Samba) problems are valid here?
(Samba generate not corrected file)+(Heimdal Kerberos FreeBSD not trying force
a tcp? PS: similar problem are not present in MIT Kerberos
(/usr/ports/security/krb5))
--
CJSC "PETER-SERVICE"
Direct: +7 812 3261290 ext. 0423
Tel: +7 812 3261299
Fax: +7 812 3261298
E-mail: [EMAIL PROTECTED]
URL: http://www.billing.ru
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, 7 Aug 2008, Dag-Erling Smørgrav wrote: > Peter Jeremy <[EMAIL PROTECTED]> writes: > > So you take each line from inetd.conf (literally) and wrap it in > > several KB of XML. This definitely adds to bloat and doesn't even > > obey the spirit of XML (since the content of each inetd.conf entry > > remains opaque). > > s/inetd/rc/g > > I completely agree with you - but I also agree with whoever it was that > suggested adding enable / disable commands to rc.subr. inetd.conf too(!); see inetconv(1M) Whilst solaris has some nice bits and pieces, the tendency to take configuration (static and dynamic) and shove it into an opaque database I personally find problematic: compare the ISC and solaris dhcp servers, for instance. enable/disable sound interesting, however. jan -- jan grant, ISYS, University of Bristol. http://www.bris.ac.uk/ Tel +44 (0)117 3317661 http://ioctl.org/jan/ ...You're visualising the _duck_ taped over my _mouth_..?___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
strange issue reading /dev/null
Hello,
I'm wondering why fgetc() returns 0xff if called with /dev/null:
#include
#include
int
main(void)
{
int c;
FILE*f;
f = fopen("/dev/null", "r");
if (c != EOF)
printf("%c\n", fgetc(f));
}
> gcc foo.c
> ./a.out
ÿ
This causes a bug in BSD grep as /dev/null is not distinguished from
ordinary files in the code, thus I was expecting it just returned EOF,
but in reality this is not the case. How such cases should be handled?
Thanks in advance,
Gábor
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, 7 Aug 2008 09:15:00 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote:
> [1]:
> $cat /usr/local/bin/service
Basically what I had in mind, but it can be made more portable across
FreeBSD configurations.
> #!/bin/sh
>
> name=$1
> cmd=$2
>
> . /etc/rc.subr
> if [ -z "${name}" -o -z "${cmd}" ]
> then
> echo ${0##*/} service_name command
> exit 3
> fi
>
>
> if [ -r "/etc/rc.d/${name}" ]
> then
> run_rc_script "/etc/rc.d/${name}" ${cmd}
> exit 0
> fi
And here's where you go wrong. What you want now is:
for dir in $local_startup; do
if [ -r "${dir}/${name}" ]
then
run_rc_script "${dir}/${name}" ${cmd}
exit 0
fi
if [ -r "${dir}/${name}.sh" ]
then
run_rc_script "${dir}/${name}.sh" ${cmd}
exit 0
fi
done
>
> echo "service '${name}' not found"
> exit 2
Thanks,
http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.
O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, 06 Aug 2008 23:16:36 -0700 Tim Kientzle <[EMAIL PROTECTED]> wrote: > > The Solaris smf tools provide some nice facilities: one is single > > interface to start, stop, check and restart all the services on a > > system. We pretty much have that ... > > > > The other is a single interface to enable, disable and query the > > status of all the services. All we really have is the last one... > > Sounds like the only missing pieces, then, are standard > ways to enable, disable, and configure services. How about: > >sudo /etc/rc.d/ssh enable >sudo /etc/rc.d/ssh disable >sudo /etc/rc.d/ssh configure > > That shouldn't be much of a stretch to implement, either. > The first two just append entries to /etc/rc.conf. The > third opens an editor with a list of variables supported > by this service and then appends the result to rc.conf. Well, that might work, but could lead to unintended consequences if you start missing settings from two different configure runs by continually appending without deleting the old settings. load_rc_config already sources /etc/rc.conf.d/"$_name". Working with that file instead of /etc/rc.conf would seem to be a cleaner solution. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. O< ascii ribbon campaign - stop html mail - www.asciiribbon.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
On Thu, 7 Aug 2008, Gabor Kovesdan wrote:
Hello,
I'm wondering why fgetc() returns 0xff if called with /dev/null:
#include
#include
int
main(void)
{
int c;
FILE*f;
f = fopen("/dev/null", "r");
if (c != EOF)
printf("%c\n", fgetc(f));
}
gcc foo.c
./a.out
ÿ
This causes a bug in BSD grep as /dev/null is not distinguished from
ordinary files in the code, thus I was expecting it just returned EOF,
but in reality this is not the case. How such cases should be handled?
You are testing c which has not been set. It works OK if you set c then
do the test:
+ c = fgetc(f);
if (c != EOF)
- printf("%c\n", fgetc(f));
+ printf("%c\n", c);
Sean
--
[EMAIL PROTECTED]___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
On Thu, 7 Aug 2008, Gabor Kovesdan wrote:
Hello,
I'm wondering why fgetc() returns 0xff if called with /dev/null:
#include
#include
int
main(void)
{
int c;
FILE*f;
f = fopen("/dev/null", "r");
if (c != EOF)
printf("%c\n", fgetc(f));
}
Hmmm, are you *sure* your code should not be written as follows:
#include
#include
int
main(int argc, char **argv)
{
FILE *f;
int c;
f = fopen("/dev/null", "r");
if (f != NULL) {
c = fgetc(f);
if (c != EOF)
printf("%c\n", c);
else
printf("EOF encountered\n");
}
return (0);
}
--
DE
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
On Thu, Aug 07, 2008 at 04:46:37PM +0200, Gabor Kovesdan wrote:
> Hello,
>
> I'm wondering why fgetc() returns 0xff if called with /dev/null:
>
> #include
> #include
>
> int
> main(void)
> {
>int c;
>FILE*f;
>
>f = fopen("/dev/null", "r");
>
>if (c != EOF)
>printf("%c\n", fgetc(f));
> }
>
> > gcc foo.c
> > ./a.out
> ÿ
>
> This causes a bug in BSD grep as /dev/null is not distinguished from
> ordinary files in the code, thus I was expecting it just returned EOF,
> but in reality this is not the case. How such cases should be handled?
Your code is wrong -- you're not calling feof(). Please read
the RETURN VALUES section of fgetc(3) in full, and slowly. :-)
And your if() statement serves no purpose there.
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
On Thu, 7 Aug 2008, Gabor Kovesdan wrote:
Sean C. Farley ha scritto:
You are testing c which has not been set. It works OK if you set c
then do the test:
+ c = fgetc(f);
if (c != EOF)
- printf("%c\n", fgetc(f));
+ printf("%c\n", c);
Yes, you are right, this is what I meant, I'm just a bit
disorganised
Thanks!
You are welcome.
Actually, what I found odd was that the base gcc did not warn about
using an uninitialized variable using -Wall.
Obviously, test fopen() and fgetc() return codes correctly as others
have noted. I just assume you were not in your test program.
Sean
--
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
On Thu, Aug 07, 2008 at 11:54:10AM -0500, Sean C. Farley wrote:
> On Thu, 7 Aug 2008, Gabor Kovesdan wrote:
>
>> Sean C. Farley ha scritto:
>>> You are testing c which has not been set. It works OK if you set c
>>> then do the test:
>>>
>>> + c = fgetc(f);
>>> if (c != EOF)
>>> - printf("%c\n", fgetc(f));
>>> + printf("%c\n", c);
>> Yes, you are right, this is what I meant, I'm just a bit
>> disorganised
>> Thanks!
>
> You are welcome.
>
> Actually, what I found odd was that the base gcc did not warn about
> using an uninitialized variable using -Wall.
Probably because you didn't use -O. -Wall includes -Wuninitialized, but
-Wuninitialized only applies if you use optimisation. gcc won't bail if
you use -Wall without -O, for obvious reasons. Case in point:
$ gcc -Wall -o x x.c
x.c: In function 'main':
x.c:14: warning: control reaches end of non-void function
$ gcc -Wuninitialized -o x x.c
cc1: warning: -Wuninitialized is not supported without -O
$ gcc -Wall -O -o x x.c
x.c: In function 'main':
x.c:14: warning: control reaches end of non-void function
x.c:12: warning: 'c' is used uninitialized in this function
gcc -- finding new ways every day to drive programmers crazy. :-)
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
Sean C. Farley ha scritto:
You are testing c which has not been set. It works OK if you set c then
do the test:
+ c = fgetc(f);
if (c != EOF)
- printf("%c\n", fgetc(f));
+ printf("%c\n", c);
Yes, you are right, this is what I meant, I'm just a bit disorganised
Thanks!
Gábor
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
On Thu, 7 Aug 2008, Jeremy Chadwick wrote:
On Thu, Aug 07, 2008 at 11:54:10AM -0500, Sean C. Farley wrote:
On Thu, 7 Aug 2008, Gabor Kovesdan wrote:
Sean C. Farley ha scritto:
You are testing c which has not been set. It works OK if you set c
then do the test:
+ c = fgetc(f);
if (c != EOF)
- printf("%c\n", fgetc(f));
+ printf("%c\n", c);
Yes, you are right, this is what I meant, I'm just a bit
disorganised
Thanks!
You are welcome.
Actually, what I found odd was that the base gcc did not warn about
using an uninitialized variable using -Wall.
Probably because you didn't use -O. -Wall includes -Wuninitialized,
but -Wuninitialized only applies if you use optimisation. gcc won't
bail if you use -Wall without -O, for obvious reasons. Case in point:
You are correct; I did not use -O.
$ gcc -Wall -o x x.c
x.c: In function 'main':
x.c:14: warning: control reaches end of non-void function
$ gcc -Wuninitialized -o x x.c
cc1: warning: -Wuninitialized is not supported without -O
Heh.
$ gcc -Wall -O -o x x.c
x.c: In function 'main':
x.c:14: warning: control reaches end of non-void function
x.c:12: warning: 'c' is used uninitialized in this function
gcc -- finding new ways every day to drive programmers crazy. :-)
Grr! Optimization should not be a requirement for checking for
uninitialized variables. Yes, gcc adds "fun" to development.
Sean
--
[EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, Aug 07, 2008 at 11:29:49AM +0100, Matthew Seaman wrote: > Jeremy Chadwick wrote: > > On Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: > >> To who it may concern, > >> > >>I am A FreeBSD administrator as well as a Solaris Administrator. I use > >> BSD at home but Solaris at work. I love both OS's but I would like to > >> increase the administrative capability of FreeBSD. > >> > >>In Solaris 10 the Services Management Facility (SMF) was introduced. > >> Basically what it does, is take all the rc.d scripts and puts them into > >> a database to manage. Everything is converted to XML and two basic > >> commands (svcs and svcadm) are used to manage everything. > > > > I highly recommend you and anyone advocating the use of XML for such > > things read the following whitepaper/study, in full: > > > > http://www.cs.kent.ac.uk/pubs/2004/2102/content.pdf > > > > Heh. Loved all the little asides to Nancy... Amazing it hasn't been > fixed in 4 years. > > Anyhow, yes: ASN.1 is smaller, and hence faster than XML for networked > applications. Which is fine, but as far as I can see doesn't address the > question at hand. > > There are two connected questions here: > >* What technology should be used to implement the FreeBSD rc.subr > system? > >* What functionality could or should be added to the FreeBSD rc.subr > system? > > Where the answer to the first question clearly constrains the results > of the second. So what are the requirements for the rc system? Off > the top of my head -- and I've probably missed some vital considerations > here -- in order of priority: > >1 reliability. The system has to boot up. > >2 repeatability. The system has to boot up in a consistent state > >3 fault tolerance. The system cannot fail to boot up unless the > problems really are terminal. > >4 configurability. The system has to boot up correctly for all > conceivable combinations of hardware and software. > >5 portability. Should run on anything from the smallest of > embedded devices to the most enormous high power super computers > to the most transient of virtualized hosts. > >6 manageability. Must be comprehensible by ordinary mortals. > >7 efficiency. Must bring the system up as fast as is practicable and > without excessive use of system resources > > What does XML-based technology bring to this? As the OP states the primary > benefit is in manageability. I would contend that the advantage claimed > here is rather less significant than indicated. We already have a central > database of configuration information -- /etc/rc.conf -- and while we don't > have one single application to control starting and stopping services we > have the next best thing: a consistent user interface for calling the > individual rc-scripts. Indeed, as other posters have shown elsewhere in > this thread, adding that sort of functionality is only a Small Matter of > Programming using the existing tools. > > What's wrong wwith using XML? XML adds significantly to the complexity of > an rc system -- it's suddenly necessary to have another shlib or two and > several compiled applications available early in the boot process. XML > itself is too general-purpose: it has too much baggage designed for its > primary function of facilitating interoperation between diverse systems in > different zones of control, none of which is particularly applicable to > system startup. While in general I agree with You, I must note that We already have xml parser (expat 1.95) for geom. See /lib/libbsdxml.so* -- Adios ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
Sean C. Farley ha scritto:
On Thu, 7 Aug 2008, Gabor Kovesdan wrote:
Sean C. Farley ha scritto:
You are testing c which has not been set. It works OK if you set c
then do the test:
+ c = fgetc(f);
if (c != EOF)
- printf("%c\n", fgetc(f));
+ printf("%c\n", c);
Yes, you are right, this is what I meant, I'm just a bit
disorganised
Thanks!
You are welcome.
Actually, what I found odd was that the base gcc did not warn about
using an uninitialized variable using -Wall.
Obviously, test fopen() and fgetc() return codes correctly as others
have noted. I just assume you were not in your test program.
Actaually, I wanted to track down why BSD grep echoed the y with the
diaresis when I executed grep . program, but I should have taken more care. As a result, I could find
the bug in grep, it was not enough to check !feof() in the for
iteration, I needed to check for EOF right after calling fgetc() and
break if it matched.
Gábor
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: restore of file system into USB key terrible slow
On Tue, Aug 05, 2008 at 11:40:13AM +0200, Matthias Apitz wrote: > What means 'Header with wrong dumpdate'? It's a warning message that probably shouldn't be printed, but has no impact other than the printing of the warning. We've fixed bug that causes it to be printed recently. David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: IPv6 CVS
On Tue, Aug 05, 2008 at 10:34:09PM +0100, Bruce Cran wrote: > The problem is cvsupd - since it's written in Modula3 and doesn't > support IPv6 you have to use an inetd/netcat hack to accept IPv6 > connections on the server. As mentioned in > http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086710.html > cvsup18.freebsd.org and cvsup4.ru.freebsd.org both accept IPv6 > connections. cvsup.ie.freebsd.org also offers cvsup over IPv6: http://lists.freebsd.org/pipermail/freebsd-stable/2003-July/001983.html Amazingly, it was announced exactly 5 years to the day before the message about cvsup18 above. David. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: strange issue reading /dev/null
On 2008-Aug-07 12:19:20 -0500, "Sean C. Farley" <[EMAIL PROTECTED]> wrote: >Grr! Optimization should not be a requirement for checking for >uninitialized variables. Yes, gcc adds "fun" to development. This is documented: `-Wuninitialized' Warn if an automatic variable is used without first being initialized or if a variable may be clobbered by a `setjmp' call. These warnings are possible only in optimizing compilation, because they require data flow information that is computed only when optimizing. If you do not specify `-O', you will not get these warnings. Instead, GCC will issue a warning about `-Wuninitialized' requiring `-O'. That explanation makes sense. -- Peter Jeremy Please excuse any delays as the result of my ISP's inability to implement an MTA that is either RFC2821-compliant or matches their claimed behaviour. pgpbGTh3Gd3ll.pgp Description: PGP signature
Re: IPv6 CVS
On Thursday 07 August 2008 19:47:31 David Malone wrote: > On Tue, Aug 05, 2008 at 10:34:09PM +0100, Bruce Cran wrote: > > The problem is cvsupd - since it's written in Modula3 and doesn't > > support IPv6 you have to use an inetd/netcat hack to accept IPv6 > > connections on the server. As mentioned in > > http://lists.freebsd.org/pipermail/freebsd-current/2008-July/086710.html > > cvsup18.freebsd.org and cvsup4.ru.freebsd.org both accept IPv6 > > connections. > > cvsup.ie.freebsd.org also offers cvsup over IPv6: > > http://lists.freebsd.org/pipermail/freebsd-stable/2003-July/001983.html Thanks David, I just tried cvsup.ie.freebsd.org and it worked a treat as well.. I appreciate the information. > Amazingly, it was announced exactly 5 years to the day before the > message about cvsup18 above. Synchronisities... Dont you just love them ;> I thought about setting up a v6 cvsup server, if the community thought that another mirror would be useful. Don't know how that may be received, however.. Useful or just redundant? Peg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Wed, Aug 06, 2008 at 11:16:36PM -0700, Tim Kientzle wrote: > >The Solaris smf tools provide some nice facilities: one is single > >interface to start, stop, check and restart all the services on a > >system. We pretty much have that ... > >The other is a single interface to enable, disable and query the > >status of all the services. All we really have is the last one... > > Sounds like the only missing pieces, then, are standard > ways to enable, disable, and configure services. How about: > > sudo /etc/rc.d/ssh enable > sudo /etc/rc.d/ssh disable > sudo /etc/rc.d/ssh configure > > That shouldn't be much of a stretch to implement, either. > The first two just append entries to /etc/rc.conf. The > third opens an editor with a list of variables supported > by this service and then appends the result to rc.conf. Pretty much the same came to my mind some weeks ago. I'd propose a "rcadm" command like Solaris' svcadm, so you do not need to care about if the rc script is in /etc/rc.d or in /usr/local/etc/rc.d. And it would be safer to check if the service is already listed in rc.conf, so it doesn't get appended every time you enable a service. pgp4PjNWFD9J7.pgp Description: PGP signature
Re: Idea for FreeBSD
On Thu, Aug 07, 2008 at 07:02:30PM +1000, Peter Jeremy wrote: > On 2008-Aug-06 19:14:51 -0400, [EMAIL PROTECTED] wrote: > > In Solaris 10 the Services Management Facility (SMF) was introduced. > > The main purpose of SMF appears to be to drum up business for Sun's > training courses by radically changing Sol10 Administration for little > benefit. The main purpose of SMF was to make it possible to programmatically control the system and deal with the myriad of different types of faults from the gazillion different things that people want to run on machines. It's complex because it has to deal with the real world. > >Basically what it does, is take all the rc.d scripts and puts them into > >a database to manage. Everything is converted to XML and two basic > >commands (svcs and svcadm) are used to manage everything. Actually, the inputs to the database are in XML, and this is distilled down to a binary representation in a sqlite database that actually drives the system. While the "svccfg" and "svcadm" interfaces do give you a single manner of dealing with the database (svccfg) and then the state of a given service (svcadm). The other thing that the SMF system captures entirely is the dependencies between the different daemons and services. I'm not sure that the rcorder stuff in FreeBSD is quite as complete. It could be, I just don't know. Also, there is versioning for the changes of the sqlite database in Solaris, so you can punt back to a earlier configuration without much hassle. > With FreeBSD, I can configure virtually all the system via a single > text file - which is easily found and kepy under configuration control. > With Sol10, there are random bits of configuration spread all over the > system and there is no obvious way to control configuration. Well, realistically, the sum of the files in /etc/rc.d and /usr/local/etc/rc.d are also needed, and you need a snapshot of all of those at a given instant in time to provably know how the system is going to configure when booted. -Kurt ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Suggestion for 'pkg_add -r'
On Thu, 07 Aug 2008 22:40:35 +0200, Lars Engels <[EMAIL PROTECTED]> wrote: On Thu, Aug 07, 2008 at 03:47:24PM +0200, Anders Nore wrote: >> >>RELENG_7: >>http://home.no.net/andenore/patches/pkg_install_2008-08-06_RELENG_7.diff >> >>CURRENT: >>http://home.no.net/andenore/patches/pkg_install_2008-08-06_CURRENT.diff > >Some comments: > * I think you have reversed the patch. :-) > * Build errors: >cc1: warnings being treated as errors >file.c:433: warning: no previous prototype for 'power' >file.c:452: warning: no previous prototype for 'human_readable' >file.c:474: warning: no previous prototype for 'printHumanReadable' >file.c: In function 'printHumanReadable': >file.c:482: warning: comparison between signed and unsigned > >parallels# ./pkg_add -r joe >Fetching 321.2 kB from >ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/Latest/joe.tbz... > Downloading: 100% 321.2 kB at 214.8 kB/s > Done >Fetching 2.4 MB from >ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/All/gettext-0.17_1.tbz... > Done >Fetching 2.2 MB from >ftp://ftp.freebsd.org/pub/FreeBSD/ports/i386/packages-8-current/All/aspell-0.60.6_2.tbz... > Downloading: 201%4.5 MB at 149.5 kB/s > >Something's wrong :-) > Heh, yes. It's my first patch(es), so it didn't go as well as I had hoped, I believe they are fixed now. I just downloaded the patch and still get the warning: /usr/src/usr.sbin/pkg_install/lib/file.c: In function 'printHumanReadable': /usr/src/usr.sbin/pkg_install/lib/file.c:486: warning: comparison between signed and unsigned *** Error code 1 Stop in /usr/src/usr.sbin/pkg_install/lib. Hey, it should be fixed now. I don't know why this causes a stop in the compiling though? Thanks, Anders Nore ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
read with timeout ??
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have my head lost in a code problem. I just hit a point where I need to do a read from an fd, but I need to associate it with a timeout, on the order of 1 second, something like that. I had the feeling that there's a function in FreeBSD's libc that makes that simple, but I forget the function name. If anyone can remember something like what I'm talking about, I sure would appreciate a function name. I can figure out how it works, if I could only dredge up that name. I just wouldn't like to come up with 4 pounds of code where it ought to be done with a 1-liner. If you're curious, I'm still working on that tablet driver for FreeBSD. It's taken me this long to figure out that Xorg driver code. The Xorg folks have been helpful, but basically, there's almost no docs, nearly no comments, and testing a driver isn't the easiest thing in the world. Regardless, I'm getting really close on this, finally. Thanks -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkibnQoACgkQz62J6PPcoOlIaQCdG5R0p0X/hXVYh/qkX/zK63/E y+EAn3ahlXnPGPzqSdVdhbx1YsEjT4qr =bA6Z -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: read with timeout ??
On Thu, 7 Aug 2008, Chuck Robey wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have my head lost in a code problem. I just hit a point where I need to do a read from an fd, but I need to associate it with a timeout, on the order of 1 second, something like that. I had the feeling that there's a function in FreeBSD's libc that makes that simple, but I forget the function name. If anyone can remember something like what I'm talking about, I sure would appreciate a function name. I can figure out how it works, if I could only dredge up that name. man 2 select -- Nate Eldredge [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
I am surprised by the overwhelming response that this thread has acquired. I have spent the majority of the day reading all the responses that everyone has put forward. I would like to clear a few things up, comment on others, and suggest some solutions to a lot of good points that everyone has made so far. First let me reiterate a few things. I started in FreeBSD and it will always be my first love. Second, keep in mind that Solaris is a commercial product and must be viewed as such. Now that that is out of the way. I want to make it clear to everyone that I was not suggesting the idea of copying or reproducing any part of how Sun manages or implements its services; only the CONCEPT of how they do it. It does not have to be XML, or in a database or anything else. Actually I am thinking more along the lines of a wrapper that can read/modify/execute from rc.d and the rc.conf. After all, we do not want to make drastic changes. No one wants to re-write rc's or move them to another location. Even solaris still relies on rc scripts to exist. And I am sure I speak for all of us when I say that we all love the concept of how rc.conf handles everything. As some people have already pointed out multiple times so far, the idea of an enable/disable is a great idea. Maybe we can start with that and see how it goes and develop further based on need/requirements/accomplishments. I think a drop-in command like "rcadm" (someone mentioned this as an idea, but cant remember who) would be a good start for managing the states of services. Mike Meyer also brought up many good points that I agree with. Please try not to get caught up in the XML stuff, that is not a requirement or suggestion, it is just an example of how Sun did it, now how FreeBSD has to;) Someone recommended Puppet, but this is an entire framework that would have to be added/implemented and configured to work with FreeBSD as well as learning a new markup language for it. launchd has a lot of good ideas, but I am not sure how mature it is yet; maybe it is a good place to start. If we start with the basics and break it down and program this from a modular standpoint it is not so bad. Begin with the basic (high-level) approach. A shell script (service) that is aware of where rc scripts are located and that can keep track of what the current state of the services (PID's) are. An enable/disable command is nothing more that throwing a start/stop command to these rc files. The rc.conf can assist with knowing what should be enabled/disabled and what flags to throw at it. For EXAMPLE, (you got that, example only) Solaris uses one master service that is started first, and the whole point of that first service is to monitor the other services and know what state they are in and starts dependent services upon boot. Consider it the service manager almost. I could go on plenty about different ways this concept could be implemented but lets not go in the weeds to deep. A systematic approach to this would be the basics. Lets start with the idea of a enable/disable and go from there. On a side not, I am impressed with many of the points that were made and ideas already generated and all within less than 24 hours. I am glad I joined this list. Thank you all. > To who it may concern, > >I am A FreeBSD administrator as well as a Solaris Administrator. I use > BSD at home but Solaris at work. I love both OS's but I would like to > increase the administrative capability of FreeBSD. > >In Solaris 10 the Services Management Facility (SMF) was introduced. > Basically what it does, is take all the rc.d scripts and puts them into > a database to manage. Everything is converted to XML and two basic > commands (svcs and svcadm) are used to manage everything. > >I would like to submit the idea of implementing a similar environment > into FreeBSD. After looking through the developers links and googling I > found no project for FreeBSD that implemented anything similar to this. > I have included a link below to give a better understanding of SMF and > its capabilities. > >Is it possible, if it does not exist already, to look at the > possibility of implementing the concept of SMF into FreeBSD? I would > gladly be an active supporter in this endeavor. > > > Will Bentley > Future CIS > 410-782-5954 > "Your resource for computer expertise!" > > ___ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: read with timeout ??
On Thu, Aug 7, 2008 at 10:14 PM, Nate Eldredge <[EMAIL PROTECTED]> wrote: > On Thu, 7 Aug 2008, Chuck Robey wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> I have my head lost in a code problem. I just hit a point where I need to >> do a >> read from an fd, but I need to associate it with a timeout, on the order >> of 1 >> second, something like that. I had the feeling that there's a function in >> FreeBSD's libc that makes that simple, but I forget the function name. If >> anyone can remember something like what I'm talking about, I sure would >> appreciate a function name. I can figure out how it works, if I could >> only >> dredge up that name. > > man 2 select If the fd is a socket then you can also use setsockopt(2) to set SO_RCVTIMEO and check for EWOULDBLOCK (same as EAGAIN) upon read(2) or recv(2) errors. The net effect is the same of using select but the syntax is simpler, IMO. -- If you think things can't get worse it's probably only because you lack sufficient imagination. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Idea for FreeBSD
On Thu, Aug 07, 2008 at 11:25:39AM -0400, Mike Meyer wrote:
> On Thu, 7 Aug 2008 09:15:00 +0300 Alex Kozlov <[EMAIL PROTECTED]> wrote:
> > [1]:
> > $cat /usr/local/bin/service
>
> Basically what I had in mind, but it can be made more portable across
> FreeBSD configurations.
>
[...]
>
> And here's where you go wrong. What you want now is:
Yes. This is more correct:
#!/bin/sh
name=$1
cmd=$2
if [ -z "${name}" -o -z "${cmd}" ]; then
echo ${0##*/} service_name command
exit 3
fi
. /etc/rc.subr
load_rc_config ${name}
for dir in /etc/rc.d ${local_startup}; do
if [ -r "${dir}/${name}" ]; then
run_rc_script "${dir}/${name}" ${cmd}
exit 0
fi
if [ -r "${dir}/${name}.sh" ]; then
run_rc_script "${dir}/${name}.sh" ${cmd}
exit 0
fi
done
echo "service '${name}' not found"
exit 2
--
Adios
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
