Re: Q: case studies about scalable, enterprise-class firewall w/ IPFilter
Well, there are always Juniper Networks boxes :-) I do the same (even more in some points) as Juniper boxes with simple standard boxes with OpenBSD and PF. At present day my central FWs are simply standard 2 boxes (each one cost 1000 euros aprox); I remember the Juniper guy offering me a 'cheap' 7000/12000 euros solution.. :P Moreover, as far I know, the core of Juniper devices is BSD (FreeBSD especially) based. -- Thanks, Jordi Espasa Clofent ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Q: case studies about scalable, enterprise-class firewall w/ IPFilter
On Wed, Aug 06, 2008 at 10:21:51AM +0200, Jordi Espasa Clofent wrote: >> Well, there are always Juniper Networks boxes :-) > > I do the same (even more in some points) as Juniper boxes with simple > standard boxes with OpenBSD and PF. > > At present day my central FWs are simply standard 2 boxes (each one cost > 1000 euros aprox); I remember the Juniper guy offering me a 'cheap' > 7000/12000 euros solution.. :P I'm amazed at the fact that people are actually comparing FreeBSD with pf to Juniper routers. I've a bit of experience with M20s and M40s, and I can assure you they're VERY different than a little x86 PC routing packets, and are significantly faster due to hardware routing. For example, you should be aware of a pf(4) bug that was only recently fixed. Our FreeBSD systems only use ACLs + state track, and have low network I/O (600kbit/sec) -- yet this sort of thing impacts production packets on a webserver: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125261 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c Max committed the fix to CURRENT, and it should be MFC'd on the 11th. I hope it gets backported to RELENG_6 as well, since it's pretty major (IMHO). My point isn't to insult or poke fun at pf or FreeBSD. I'm simply stating "if you really think an x86 box with pf is better than a Juniper, you're sadly mistaken". I'm not telling you to go out and buy a Juniper either, especially if it's out of your price range -- but you really need to be more aware of the differences before toting the "my FreeBSD box can do the job better!" attitude. I'm glad FreeBSD with pf works for you, though. > Moreover, as far I know, the core of Juniper devices is BSD (FreeBSD > especially) based. Correct, JunOS is FreeBSD 4.x-based. On the other hand, I find it amusing that Juniper's routers use ATA disks. A single disk failure results in the system becoming unusable administratively (requiring a reboot), while the routing engine still works fine (e.g. packets are still routed properly, ACLs applied, etc.). Config data is kept on CF, so that isn't lost. You just can't SSH into it, and all you'll see on serial console is repetitive ATA and SMART errors. I've seen this happen on three separate routers on three separate occasions at my workplace. For something that costs so much money, you'd have expected them to go with some form of disk redundancy, SCSI disks, or SSDs. -- | 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: Q: case studies about scalable, enterprise-class firewall w/ IPFilter
I'm amazed at the fact that people are actually comparing FreeBSD with pf to Juniper routers. I've a bit of experience with M20s and M40s, and I can assure you they're VERY different than a little x86 PC routing packets, and are significantly faster due to hardware routing. For example, you should be aware of a pf(4) bug that was only recently fixed. Our FreeBSD systems only use ACLs + state track, and have low network I/O (600kbit/sec) -- yet this sort of thing impacts production packets on a webserver: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/125261 http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/contrib/pf/net/pf.c Max committed the fix to CURRENT, and it should be MFC'd on the 11th. I hope it gets backported to RELENG_6 as well, since it's pretty major (IMHO). Yes. That's my main personal reason to work with OpenBSD instead of FreeBSD when I need PF dedicated device. My point isn't to insult or poke fun at pf or FreeBSD. I'm simply stating "if you really think an x86 box with pf is better than a Juniper, you're sadly mistaken". I'm not telling you to go out and buy a Juniper either, especially if it's out of your price range -- but you really need to be more aware of the differences before toting the "my FreeBSD box can do the job better!" attitude. I'm glad FreeBSD with pf works for you, though. Good reasoning Jeremy. I don't say that x86 pf-based box is better than Juniper. I only comment that, in my case, I do all I need with two standard boxes instead of expensive Juniper device. Anyway it's clear if one day the best solution is Juniper device, I will purchase it. But at present moment, isn't (300Mpbs/500Mpbs) On the other hand, I find it amusing that Juniper's routers use ATA disks. A single disk failure results in the system becoming unusable administratively (requiring a reboot), while the routing engine still works fine (e.g. packets are still routed properly, ACLs applied, etc.). Config data is kept on CF, so that isn't lost. You just can't SSH into it, and all you'll see on serial console is repetitive ATA and SMART errors. I've seen this happen on three separate routers on three separate occasions at my workplace. Interesting. My OpenBSD+PF FWs runs at present with ATA disks also, but I'm designing a CF-based new implementation. ;) -- Thanks, Jordi Espasa Clofent ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
USB key && kernel: da0: Attempt to query device size failed: UNIT ATTENTION, Medium not present
Hello, 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: what makes me worry is that the problem was raised in 5.4-RC3 in 2005 and still exists in 7.0R in 2008, or have I overlooked some cool system parameter to fix this; 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: Q: case studies about scalable, enterprise-class firewall w/ IPFilter
Jeremy Chadwick wrote: > On Wed, Aug 06, 2008 at 10:21:51AM +0200, Jordi Espasa Clofent wrote: >>> Well, there are always Juniper Networks boxes :-) >> I do the same (even more in some points) as Juniper boxes with simple >> standard boxes with OpenBSD and PF. >> >> At present day my central FWs are simply standard 2 boxes (each one cost >> 1000 euros aprox); I remember the Juniper guy offering me a 'cheap' >> 7000/12000 euros solution.. :P > > I'm amazed at the fact that people are actually comparing FreeBSD with > pf to Juniper routers. I've a bit of experience with M20s and M40s, and > I can assure you they're VERY different than a little x86 PC routing > packets, and are significantly faster due to hardware routing. > The M series is hardware routed but IIRC the J series is routed in software. The performance numbers for this series are pretty close to what FreeBSD can do with the right hardware and network cards and for a lot less money. FreeBSD can also outperform many of the SSG's and NetScreen's - up to the 550/500 I think. That said, Juniper still offers numerous features that are worthwhile, even in the J, SSG and NetScreen series. You just have to need those features in order for it to make any sense. Regards, Chris ___ 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: > 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". If that doesn't help, please try this patch: === --- src/sys/dev/usb/umass.c.orig2008-05-21 16:22:03.0 +0200 +++ src/sys/dev/usb/umass.c 2008-08-06 19:23:01.0 +0200 @@ -2690,7 +2690,7 @@ * completed, when interrupts have been enabled. */ - callout_reset(&sc->cam_scsi_rescan_ch, MS_TO_TICKS(200), + callout_reset(&sc->cam_scsi_rescan_ch, MS_TO_TICKS(2000), umass_cam_rescan, sc); } === Note that this patch is not a solution. It's purpose is to find out if the cause of your problem is the same as the one in PR usb/80361. If it is, the patch from the PR should be committed (it introduces a quirk for cases like this), and your USB stick should be added to the quirks list. 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 "The last good thing written in C was Franz Schubert's Symphony number 9." -- Erwin Dieterich ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
options MAC vs. pkg_add
Hi List, I am running into a weird issue. On a 6.2 stable, 32bits built with options MAC, I can run pkg_add of anything. But a 6.2 stable, 64bits built with MAC won't let me do pkg_add. If anybody has an input, please advise. Below is the output on the 64 bits machine: net3# pkg_add test.tbz +CONTENTS: Can't update time for +CONTENTS: Operation not permitted pkg_add: tar extract of /wr/home/webmgr/test.tbz failed! pkg_add: unable to extract table of contents file from '/wr/home/webmgr/test.tbz' - not a package? net3# net3# tar xvf test.tbz x +CONTENTS: Can't update time for +CONTENTS: Operation not permitted x +COMMENT: Can't update time for +COMMENT: Operation not permitted x +DESC: Can't update time for +DESC: Operation not permitted x +DISPLAY: Can't update time for +DISPLAY: Operation not permitted x usr/local/bin/sudo: Can't update time for usr/local/bin/sudo: Operation not permitted x usr/local/man/man8/sudo.8: Can't update time for usr/local/man/man8/sudo.8: Operation not permitted x usr/local/man/man8/visudo.8: Can't update time for usr/local/man/man8/visudo.8: Operation not permitted x usr/local/man/man5/sudoers.5 x usr/local/sbin/visudo: Can't update time for usr/local/sbin/visudo: Operation not permitted x usr/local/libexec/sudo_noexec.so: Can't update time for usr/local/libexec/sudo_noexec.so: Operation not permitted x usr/local/libexec/sudo_noexec.la: Can't update time for usr/local/libexec/ sudo_noexec.la: Operation not permitted x etc/sudoers: Can't update time for etc/sudoers: Operation not permitted net3# uname -a FreeBSD net3 6.2-STABLE FreeBSD 6.2-STABLE #1: Tue Aug 5 15:10:45 PDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/MYBD<[EMAIL PROTECTED]:/usr/obj/usr/src/sys/MPATH-nonsec> amd64 thanks, Jerry ___ 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 (06/08/2008 19:29), 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:
Situation here is somewhat opposite. Device doesn't attach at boot or
attaches some times. And needs special patch to attach later.
% usbdevs -v
port 1 addr 2: high speed, power 300 mA, config 1, USB DRIVE(0x0111),
0(0x04e8), rev 2.00
>
> 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".
>
> If that doesn't help, please try this patch:
>
> ===
> --- src/sys/dev/usb/umass.c.orig 2008-05-21 16:22:03.0 +0200
> +++ src/sys/dev/usb/umass.c 2008-08-06 19:23:01.0 +0200
> @@ -2690,7 +2690,7 @@
>* completed, when interrupts have been enabled.
>*/
>
> - callout_reset(&sc->cam_scsi_rescan_ch, MS_TO_TICKS(200),
> + callout_reset(&sc->cam_scsi_rescan_ch, MS_TO_TICKS(2000),
> umass_cam_rescan, sc);
> }
With this patch it gives following error:
Aug 6 23:33:44 h1 kernel: umass0: <0 USB DRIVE, class 0/0, rev 2.00/2.00, addr
2> on uhub2
Aug 6 23:33:46 h1 kernel: da0 at umass-sim0 bus 0 target 0 lun 0
Aug 6 23:33:46 h1 kernel: da0: < USB DRIVE 2.00> Removable Direct Access
SCSI-2 device
Aug 6 23:33:46 h1 kernel: da0: 40.000MB/s transfers
Aug 6 23:33:46 h1 kernel: da0: Attempt to query device size failed: UNIT
ATTENTION, Not ready to ready change,
I've tried to increase delay up to 4000, nothing changed.
Without patch error message is different. Can reproduce it if somebody
is interested in it.
But what surprises is that with this patch device attaches during boot.
> Note that this patch is not a solution. It's purpose is
> to find out if the cause of your problem is the same as
> the one in PR usb/80361. If it is, the patch from the PR
> should be committed (it introduces a quirk for cases like
> this), and your USB stick should be added to the quirks
> list.
I've been using another homemade patch for >2 years. Hope it can help to
find a real solution. I have no idea what it does, I'm not sure a had
one during writing it back then. Anyway key attaches and just works.
diff -r 24788dc12d11 -r 519a067f2475 sys/dev/usb/umass.c
--- a/sys/dev/usb/umass.c Sat Jun 03 13:05:16 2006 +0300
+++ b/sys/dev/usb/umass.c Sat Jun 03 13:08:35 2006 +0300
@@ -2514,7 +2514,7 @@ umass_cam_action(struct cam_sim *sim, un
sense->extra_len = 10;
ccb->csio.scsi_status = SCSI_STATUS_CHECK_COND;
ccb->ccb_h.status = CAM_SCSI_STATUS_ERROR |
- CAM_AUTOSNS_VALID;
+ /* CAM_AUTOSNS_VALID */ 0;
xpt_done(ccb);
return;
}
@@ -2805,7 +2805,7 @@ umass_cam_sense_cb(struct umass_softc *s
*/
ccb->ccb_h.status = CAM_SCSI_STATUS_ERROR
- | CAM_AUTOSNS_VALID;
+ | /* CAM_AUTOSNS_VALID */ 0;
csio->scsi_status = SCSI_STATUS_CHECK_COND;
#if 0
@@ -2836,7 +2836,7 @@ umass_cam_sense_cb(struct umass_softc *s
break;
} else {
ccb->ccb_h.status = CAM_SCSI_STATUS_ERROR
- | CAM_AUTOSNS_VALID;
+ | /* CAM_AUTOSNS_VALID */ 0;
csio->scsi_status = SCSI_STATUS_CHECK_COND;
}
xpt_done(ccb);
@@ -2872,7 +2872,7 @@ umass_cam_quirk_cb(struct umass_softc *s
ccb->ccb_h.status = CAM_REQ_CMP;
#endif
ccb->ccb_h.status = CAM_SCSI_STATUS_ERROR
- | CAM_AUTOSNS_VALID;
+ | /* CAM_AUTOSNS_VALID */ 0;
ccb->csio.scsi_status = SCSI_STATUS_CHECK_COND;
xpt_done(ccb);
}
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Idea for FreeBSD
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]"
Re: Idea for FreeBSD
On Wed, Aug 6, 2008 at 7:14 PM, <[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 XML is good at document processing and for portable self-describing databases. Otherwise, I would think significantly less of any OS (or application) that used XML for configuration data. At least nothing that anyone would *every* be forced to edit manually. 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. 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. Just my 2c, Mike PS: I'm not a FreeBSD "hacker" or even an admin. ___ 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 6, 2008 at 7:14 PM, <[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 > > XML is good at document processing and for portable self-describing > databases. Otherwise, I would think significantly less of any OS (or > application) that used XML for configuration data. At least nothing > that anyone would *every* be forced to edit manually. > > 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. > > 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. > > Just my 2c, > Mike > > PS: I'm not a FreeBSD "hacker" or even an admin. > ___ I believe the puppet project has a lot of potential, or if not the project then at least the ideas behind it, in regard to automating administrative tasks. I particularly like the way it allows the automation of the same tasks across different operating systems. http://reductivelabs.com/trac/puppet/ Cheers, Tim. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em0: The EEPROM Checksum Is Not Valid
Hello my trouble with nic part of `dmesg` output - em0: port 0xec00-0xec3f mem 0xfebc-0xfebd,0xfeb8-0xfebb irq 19 at device 2.0 on pci2 em0: The EEPROM Checksum Is Not Valid device_attach: em0 attach returned 5 -- part of `pciconf -lv` output -- [EMAIL PROTECTED]:2:2:0: class=0x02 card=0x10018086 chip=0x10268086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82545GM Gigabit Ethernet Controller' class = network subclass = ethernet -- uname output -- FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #2: Wed Jul 16 20:36:12 UTC 2008 root@:/usr/obj/usr/src/sys/STONE i386 -- please, any solution? /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: Idea for FreeBSD
0n Wed, Aug 06, 2008 at 07:14:51PM -0400, [EMAIL PROTECTED] wrote: >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. I believe there was a port of MacOS-X 'launchd' to FreeBSD: [http://wiki.freebsd.org/launchd] I think launchd may use XML. -aW IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
em0: The EEPROM Checksum Is Not Valid
Hello my trouble with nic part of `dmesg` output - em0: port 0xec00-0xec3f mem 0xfebc-0xfebd,0xfeb8-0xfebb irq 19 at device 2.0 on pci2 em0: The EEPROM Checksum Is Not Valid device_attach: em0 attach returned 5 -- part of `pciconf -lv` output -- [EMAIL PROTECTED]:2:2:0: class=0x02 card=0x10018086 chip=0x10268086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82545GM Gigabit Ethernet Controller' class = network subclass = ethernet -- uname output -- FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #2: Wed Jul 16 20:36:12 UTC 2008 root@:/usr/obj/usr/src/sys/STONE i386 -- please, any solution? /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: em0: The EEPROM Checksum Is Not Valid
On Thu, Aug 07, 2008 at 08:34:44AM +0400, Vladimir Ermakov wrote: > Hello > > my trouble with nic > > part of `dmesg` output > - > em0: port 0xec00-0xec3f mem > 0xfebc-0xfebd,0xfeb8-0xfebb irq 19 at device 2.0 on pci2 > em0: The EEPROM Checksum Is Not Valid > device_attach: em0 attach returned 5 > -- > > part of `pciconf -lv` output > -- > [EMAIL PROTECTED]:2:2:0: class=0x02 card=0x10018086 chip=0x10268086 > rev=0x01 > hdr=0x00 >vendor = 'Intel Corporation' >device = '82545GM Gigabit Ethernet Controller' >class = network >subclass = ethernet > -- > > uname output > -- > FreeBSD 7.0-STABLE FreeBSD 7.0-STABLE #2: Wed Jul 16 20:36:12 UTC 2008 > root@:/usr/obj/usr/src/sys/STONE i386 > -- > > please, any solution? Intel probably has a utility to reset the EEPROM settings on the NIC. Jack Vogel may know where to get such a utility. I do not believe this problem is FreeBSD-related. -- | 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: Idea for FreeBSD
On Wed, 6 Aug 2008 22:34:51 -0400 "Michael B Allen" <[EMAIL PROTECTED]> wrote: > On Wed, Aug 6, 2008 at 7:14 PM, <[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 > > XML is good at document processing and for portable self-describing > databases. Otherwise, I would think significantly less of any OS (or > application) that used XML for configuration data. At least nothing > that anyone would *every* be forced to edit manually. Give the right tools, editing XML is actually reasonable. The right tools are a schema for the documents in question, a schema-aware editor, and applications software that bitches if the document doesn't match the schema. The problem is that you almost never get a schema, and having an application that cares is even rarer. Without those, you're best off using application tools to manipulate the documents, and never touching it except for emergencies. In which case: > 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. 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. The only thing decrepit about the rc.d scripts is that they don't all support the latest facilities that you'd expect them to. But the way to fix that is to update the old ones, not to throw out all of them and start over. In particular, if you want to replace them with a better format, you need to start by showing that said format is better - and chanting buzzwords like "xml" isn't sufficient to do that. You could, for instance, get all of the facilities of svcs with a shell script that grokked the current rc.d formats. Searching wouldn't be quite as spiffy because we don't have the concept of an FMRI, and getting the output formatting facilities right would be a bit tricky, but the information is pretty much all there. svcadm is a bit harder, because you'd have to edit rc.conf in place, but again, most of the pieces are already in place. 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 Thu, Aug 7, 2008 at 1:06 AM, Mike Meyer <[EMAIL PROTECTED]> wrote: > On Wed, 6 Aug 2008 22:34:51 -0400 > "Michael B Allen" <[EMAIL PROTECTED]> wrote: >> 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. > > The only thing decrepit about the rc.d scripts is that they don't all > support the latest facilities that you'd expect them to. But the way > to fix that is to update the old ones, not to throw out all of them > and start over. In particular, if you want to replace them with a > better format, you need to start by showing that said format is better > - and chanting buzzwords like "xml" isn't sufficient to do that. 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. 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. 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 (which is to say dbm or some other binary-blob format should be used since it makes programming the said library much cleaner). And for backwards compatibility you leave the rc.d tree so that a third party can drop in a script and it will continue to work but anyone using the said utility would completely bypass all the rc.d business. But I just made that up. Of course such things are never as simple as they sound the first time around. Mike ___ 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
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. Tim ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
