Re: loading modules not in /boot/kernel from loader.conf
On 11/12/2007 2:54 AM, Aryeh M. Friedman wrote: You could make a softlink... Thats what raised the question I was doing ln -s /usr/local/modules/fuse.ko /boot/kernel/fuse.ko Remember that this is the loader which will be loading the module, so if /usr is a separate partition then this will not work as /usr doesn't get mounted until much, much later in the boot process... Alternatively, if you're using your own home-brew rc script, why not just add a kldload fuse into it? --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Questions on behaviour of fetch(3) regarding HTTPS + proxy
On 22/11/2007 2:27 AM, Bill Moran wrote: It seems that if I set HTTP_PROXY, fetch(1) works just dandy, _UNLESS_ I'm trying to fetch an https document, in which case it seems to ignore HTTP_PROXY. From memory: export HTTPS_PROXY=http://myproxy:8080; --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OEM and Trademark license for Java on FreeBSD -- [EMAIL PROTECTED] no longer valid?
On 25/10/2007 2:41 PM, Pj Malloy wrote: Any help would be MUCH appreciated. I have some questions regarding the OEM and Trademark license for Java on FreeBSD. I initially sent my email inquiry to [EMAIL PROTECTED], as stated in the FreeBSD Foundation Java Download page (http://www.freebsdfoundation.org/downloads/java.shtml), but that [EMAIL PROTECTED] email address does not appear to be valid -- the email I sent to that address bounced. The [EMAIL PROTECTED] email address is specifically called out in Diablo FreeBSD OEM Java license that is listed here: http://www.freebsdfoundation.org/cgi-bin/download?download=oem/diablo-jdk-freebsd5.i386.1.5.0.07.01.tbz That license text states we (a) must obtain a Trademark License from Sun, and depending on the exact field of use, we (b) might need to get a commercial license from Sun. That license text directs me to [EMAIL PROTECTED] to get more information for both (a) and (b). That email address doesn't work, so now I'm wondering what to do next... I called Sun Sales, but they did not know what I was talking about... I too would love to know the answer to this -- the way Sun carry on, anyone would think they don't want people using their language... I am sure Microsoft don't make you jump through hoops if you want to write and distribute applications written in .NET and want to distribute the run-time along with it -- so why must Sun make it so hard for people to do that with Java? --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Intel G965 chipset?
On 14/07/2007 8:07 AM, Bruce Caruthers wrote: ... === My Question: So, can I use an Intel motherboard with the 965 chipset? If not, what is the latest chipset I can use which will meet my needs? We use the 965 based boards for many of our servers and they work fine - the only gotchas I have come across has been the onboard IDE controller is a Marvell ATA controller, and not supported by the drivers in 6.2-RELEASE. I made a back-port of the -CURRENT driver to 6.2 some months ago and have not had any problems (although the CD-ROM connected to said IDE channel is only used for the installation process!). I would imagine that the driver is likely present in 6-STABLE and the upcoming 6.3 release later this year. --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware Raid on Intel DG965OT Motherboard
On 5/04/2007 1:52 AM, Alexander Anderson wrote: Thu, Apr 05, 2007 at 08:52:44 AM, Antony Mawer wrote: I have Intel D975XBX2 with two on-board SATA RAID controllers: one is Intel Matrix and the other is Marvell storage. I have FreeBSD 6.2 with RAID-5 using Intel Matrix Storage. It seems to work fine. You may want to re-think that option... according to the ataraid(4) man page, RAID5 is not functional (ie. you have about as much data safety as a RAID0 stripe set does): CAVEATS RAID5 is not supported at this time. Code exists, but it neither uses nor maintains parity information. The ataraid driver provides *software* RAID. But doesn't Intel Matrix Storage gives *hardware* RAID support? How could I tell if software is at play? I'm fairly certain that all ar# devices (ar0, etc) are ataraid-powered, and thus are software RAID. If it is a hardware RAID device, typically the RAID controller presents a single drive (or one drive for each RAID volume) to the OS, and the OS can be ignorant of the number of underlying drives. Also, from man ataraid: The ataraid driver can read the following metadata formats: ... o Intel MatrixRAID Which suggests that is is, indeed, just a software RAID setup. That is, the BIOS-based bit just writes configuration metadata to the drives, and its up to drivers at the OS level to perform the actual RAID operations using that data. --Antony ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Hardware Raid on Intel DG965OT Motherboard
On 4/04/2007 9:30 PM, Alexander Anderson wrote: I have Intel D975XBX2 with two on-board SATA RAID controllers: one is Intel Matrix and the other is Marvell storage. I have FreeBSD 6.2 with RAID-5 using Intel Matrix Storage. It seems to work fine. ... ad4: 305245MB Seagate ST3320620AS 3.AAJ at ata2-master SATA150 ad6: 305245MB Seagate ST3320620AS 3.AAJ at ata3-master SATA150 ad8: 305245MB Seagate ST3320620AS 3.AAJ at ata4-master SATA150 ad10: 305245MB Seagate ST3320620AS 3.AAJ at ata5-master SATA150 ar0: 915729MB Intel MatrixRAID RAID5 (stripe 64 KB) status: READY ar0: disk0 READY using ad4 at ata2-master ar0: disk1 READY using ad8 at ata4-master ar0: disk2 READY using ad6 at ata3-master ar0: disk3 READY using ad10 at ata5-master You may want to re-think that option... according to the ataraid(4) man page, RAID5 is not functional (ie. you have about as much data safety as a RAID0 stripe set does): CAVEATS RAID5 is not supported at this time. Code exists, but it neither uses nor maintains parity information. One drive failure and you will be in for a whole world of hurt... --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is 'disklabel'ng a new drive so difficult?
On 29/03/2007 6:41 AM, Kris Kennaway wrote: On Wed, Mar 28, 2007 at 05:26:49PM -0300, Marc G. Fournier wrote: Just bought a new WD SATA drive: WDC WD5000YS-01MPB1 09.02E09 Tried to disklabel it, and it gives me all kinds of warnings when I look at it after running the disklabel: ganymede# bsdlabel -w ad4s1 auto ganymede# bsdlabel ad4s1c # /dev/ad4s1c: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 976767986 79unused0 0 c: 976768002 63unused0 0 # raw part, don't edit partition a: partition extends past end of unit partition c: partition extends past end of unit bsdlabel: partition c doesn't start at 0! bsdlabel: An incorrect partition c may cause problems for standard system utilities Even if I try to use /stand/sysinstall to do the fdisk, the end result has 'issues' ... So, what is the generally accepted method of label'ng a new drive? :( I learned a useful trick the other day: you can use abbreviations like 1g, also '*' to mean automatically calculate. See the manpage. This timely thread came as I was experimenting with disklabel, and I noticed in the man page it says this: offset The offset of the start of the partition from the beginning of the drive in sectors, or * to have bsdlabel calculate the correct offset to use (the end of the previous partition plus one, ignor- ing partition `c'. For partition `c', * will be interpreted as an offset of 0. The first partition should start at offset 16, because the first 16 sectors are reserved for metadata. When I tried using 16 as the offset for my 'a' partition, I could no longer user * on my last partition to make it auto-size... disklabel then sized the partition so it went past the end of the disk. Presumably it's not taking into account the starting offset when it does this (gm0 is a 3gb gmirror device, with a single slice created on it using fdisk): $ bsdlabel -R /dev/mirror/gm0s1 /dev/stdin 8 partitions: a: 2097152 164.2BSD b: 102400* swap c:*0unused d: 102400*4.2BSD e:**4.2BSD partition e: partition extends past end of unit However if I change the 'a' partition offset to 'e', it works: $ bsdlabel -R /dev/mirror/gm0s1 /dev/stdin 8 partitions: a: 209715204.2BSD b: 102400* swap c:*0unused d: 102400*4.2BSD e:**4.2BSD $ disklabel /dev/mirror/gm0s1 # /dev/mirror/gm0s1: 8 partitions: #size offsetfstype [fsize bsize bps/cpg] a: 209715204.2BSD0 0 0 b: 102400 2097152 swap c: 62813520unused0 0 # raw d: 102400 21995524.2BSD0 0 0 e: 3979400 23019524.2BSD0 0 0 Is it important to use 16 as the offset still, or is this a historical piece of information that is no longer relevant? Or is this is a bug in disklabel that should be fixed? --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Why is 'disklabel'ng a new drive so difficult?
On 30/03/2007 9:22 AM, Jerry McAllister wrote: On Fri, Mar 30, 2007 at 08:07:23AM +1000, Antony Mawer wrote: ... Is it important to use 16 as the offset still, or is this a historical piece of information that is no longer relevant? Or is this is a bug in disklabel that should be fixed? As I indicated in another post in this thread, it appears to be vestigial.I have never used it for a bsdlabel(disklabel) being done on a slice - since 1998. I just went back and re-read your other messages in the thread. I must have glossed over that part of them - my apologies! I too looked at my sysinstall-created labels, and they were all at offset of 0. I actually started writing my own partitioning/labelling tool based on libdisk, as part of a custom install CD I was building, but discovered that it did not support non-disk devices (eg. gmirror)... I started looking at trying to hack support into libdisk to do so (and made some success), but in the end decided that it was probably a task better suited for someone that knows libdisk better than I... As a result I went back to looking at fdisk/bsdlabel to see what I could do using them instead... There seems to be a lot of left over stuff in the documentation and man pages for fdisk and bsdlabel (and disk formatting, partitioning and booting in general). Someone made a pass at cleaning them up about 6 years ago and that helped, but it could stand to be done some more. If I felt knowledgeable enough, I would take a whack at it. But there are too many holes (not wholes) in my knowledge. I would guess from posts in the list that a lot of people are in that position - knowing a bunch of it, but not quite enough to be authoratative about it. I have written several long replies to questions on this list that could be the basis for FAQs or HowTo-s, but they still leave a lot of things out and generalize or slide over lots of other things for the sake of convenience, avoiding confusing a newbie and/or not being sure about all the details. I can attest to that -- I would love to see a clear, newbie friendly explanation on disk geometry, and why it is/isn't relevant in this day and age. The big scary warnings sysinstall likes to throw up made me think it must have some significance, but from days of searching/reading, the general gist I came up with is that geometry was a largely obsolete concept (as most things use LBA for addressing, including /boot/mbr from what I could tell), largely only relevant if you have other operating systems on the drive, in which case all OSes needed to agree on the drive geometry in order for the fdisk slice table to make any sense to all of them... In that case, can anyone comment with any knowledge if geometry fix-ups are only necessary if the drive is shared with non-FreeBSD operating systems? Or are they important for a drive (non-dangerously dedicated) with just a single FreeBSD slice on it? If they are needed, should some of the sysinstall magic be added to the command line fdisk tool as well (as an option), so it can perform the same modifications if it detects non-sane BIOS C/H/S values? --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: started playing with jails
On 22/03/2007 3:50 AM, Greg Barniskis wrote: Bill Moran wrote: My experiments with Postgres in jail predate the existence of that setting. When I was working with it, you had to frob a sysctl via /etc/sysctl.conf But even then, I couldn't seem to get it to work -- the Postgres in the jail would corrupt the shared memory of the postgres outside the jail. It was ugly. Imagine big, wet tears rolling down my cheeks. I haven't had the need to try it in a while, so it might work OK now, I just don't know. Ah, now that you mention it I do recall discussions of multiple instances peeing in each others pools so to speak. I also thought there was discussion of how to fix it, but have no idea where that went if anywhere... A single instance inside a jail does work quite happily if the knob above is set. From memory, I think the discussion went something like Postgres uses the TCP port number it binds to as its SYSV IPC ID... so if you want to run multiple instances in jails/etc without conflict, run them on different port numbers (and consequentially they will get separate SYSV IPC IDs). --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Can't see ATA drives with new install
On 19/03/2007 7:55 AM, [EMAIL PROTECTED] wrote:
My kernel config already includes all that.
Just installed OpenBSD, and the other drives work just fine. I guess
that's my OS.
Quite disappointing that FreeBSD is actually behind in terms of
hardware support, particularly for a relatively popular motherboard.
On 3/18/07, Garrett Cooper [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
It's an Intel DG965WH; Core 2 Duo CPU.
You may want to try the attached backport of support for the onboard
Marvell IDE controller I posted to -hardware recently. The patch is
against 6.2-RELEASE, and adds support for the onboard Marvell IDE
controller that is present on many Intel 965-based boards. To apply:
cd /usr/src
patch marvell_pata.diff
make buildkernel make installkernel
And you should be right to go.
--Antony
--- sys/dev/ata/ata-chipset.c.orig Sun Mar 11 18:33:13 2007
+++ sys/dev/ata/ata-chipset.c Sun Mar 11 18:33:42 2007
@@ -105,14 +105,17 @@
static void ata_jmicron_reset(device_t dev);
static void ata_jmicron_dmainit(device_t dev);
static void ata_jmicron_setmode(device_t dev, int mode);
-static int ata_marvell_chipinit(device_t dev);
-static int ata_marvell_allocate(device_t dev);
-static int ata_marvell_status(device_t dev);
-static int ata_marvell_begin_transaction(struct ata_request *request);
-static int ata_marvell_end_transaction(struct ata_request *request);
-static void ata_marvell_reset(device_t dev);
-static void ata_marvell_dmasetprd(void *xsc, bus_dma_segment_t *segs, int
nsegs, int error);
-static void ata_marvell_dmainit(device_t dev);
+static int ata_marvell_pata_chipinit(device_t dev);
+static int ata_marvell_pata_allocate(device_t dev);
+static void ata_marvell_pata_setmode(device_t dev, int mode);
+static int ata_marvell_edma_chipinit(device_t dev);
+static int ata_marvell_edma_allocate(device_t dev);
+static int ata_marvell_edma_status(device_t dev);
+static int ata_marvell_edma_begin_transaction(struct ata_request *request);
+static int ata_marvell_edma_end_transaction(struct ata_request *request);
+static void ata_marvell_edma_reset(device_t dev);
+static void ata_marvell_edma_dmasetprd(void *xsc, bus_dma_segment_t *segs, int
nsegs, int error);
+static void ata_marvell_edma_dmainit(device_t dev);
static int ata_national_chipinit(device_t dev);
static void ata_national_setmode(device_t dev, int mode);
static int ata_nvidia_chipinit(device_t dev);
@@ -2309,12 +2312,14 @@
struct ata_pci_controller *ctlr = device_get_softc(dev);
struct ata_chip_id *idx;
static struct ata_chip_id ids[] =
-{{ ATA_M88SX5040, 0, 4, MV5XXX, ATA_SA150, 88SX5040 },
- { ATA_M88SX5041, 0, 4, MV5XXX, ATA_SA150, 88SX5041 },
- { ATA_M88SX5080, 0, 8, MV5XXX, ATA_SA150, 88SX5080 },
- { ATA_M88SX5081, 0, 8, MV5XXX, ATA_SA150, 88SX5081 },
- { ATA_M88SX6041, 0, 4, MV6XXX, ATA_SA300, 88SX6041 },
- { ATA_M88SX6081, 0, 8, MV6XXX, ATA_SA300, 88SX6081 },
+{{ ATA_M88SX5040, 0, 4, MV50XX, ATA_SA150, 88SX5040 },
+ { ATA_M88SX5041, 0, 4, MV50XX, ATA_SA150, 88SX5041 },
+ { ATA_M88SX5080, 0, 8, MV50XX, ATA_SA150, 88SX5080 },
+ { ATA_M88SX5081, 0, 8, MV50XX, ATA_SA150, 88SX5081 },
+ { ATA_M88SX6041, 0, 4, MV60XX, ATA_SA300, 88SX6041 },
+ { ATA_M88SX6081, 0, 8, MV60XX, ATA_SA300, 88SX6081 },
+ { ATA_M88SX6101, 0, 1, MV61XX, ATA_UDMA6, 88SX6101 },
+ { ATA_M88SX6145, 0, 2, MV61XX, ATA_UDMA6, 88SX6145 },
{ 0, 0, 0, 0, 0, 0}};
char buffer[64];
@@ -2325,12 +2330,62 @@
idx-text, ata_mode2str(idx-max_dma));
device_set_desc_copy(dev, buffer);
ctlr-chip = idx;
-ctlr-chipinit = ata_marvell_chipinit;
+switch (ctlr-chip-cfg2) {
+case MV50XX:
+case MV60XX:
+ ctlr-chipinit = ata_marvell_edma_chipinit;
+ break;
+case MV61XX:
+ ctlr-chipinit = ata_marvell_pata_chipinit;
+ break;
+}
+return 0;
+}
+
+static int
+ata_marvell_pata_chipinit(device_t dev)
+{
+struct ata_pci_controller *ctlr = device_get_softc(dev);
+
+if (ata_setup_interrupt(dev))
+ return ENXIO;
+
+ctlr-allocate = ata_marvell_pata_allocate;
+ctlr-setmode = ata_marvell_pata_setmode;
+ctlr-channels = ctlr-chip-cfg1;
return 0;
}
static int
-ata_marvell_chipinit(device_t dev)
+ata_marvell_pata_allocate(device_t dev)
+{
+struct ata_channel *ch = device_get_softc(dev);
+
+/* setup the usual register normal pci style */
+if (ata_pci_allocate(dev))
+ return ENXIO;
+
+/* dont use 32 bit PIO transfers */
+ ch-flags |= ATA_USE_16BIT;
+
+return 0;
+}
+
+static void
+ata_marvell_pata_setmode(device_t dev, int mode)
+{
+device_t gparent = GRANDPARENT(dev);
+struct ata_pci_controller *ctlr = device_get_softc(gparent);
+struct ata_device *atadev = device_get_softc(dev);
+
+mode = ata_limit_mode(dev, mode, ctlr-chip-max_dma);
+mode = ata_check_80pin(dev, mode);
+if (!ata_controlcmd(dev, ATA_SETFEATURES, ATA_SF_SETXFER, 0,
Re: Sync'ng directories between two servers ...
On 8/02/2007 1:11 AM, Marc G. Fournier wrote: I've got a directory on ServerA that I would like to keep sync'd on ServerB ... to date, I've been using rsync for this, but what I hate with that is that it has to scan the whole directory on both servers to compare, putting a good load on each of them ... Is there anything out there that ppl are using successfully that just looks at ServerA, and dumps across those files that have changed since the last sync? ServerB will never have any changes made to it, other then what ServerA sends across ... Try sysutils/cpdup - I've used it in the past and it's reasonably quick and efficient. http://www.freshports.org/sysutils/cpdup/ --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: man sysinstall
On 31/01/2007 3:05 PM, Jared Barneck wrote: ... I found the answer for how to reboot in the code. To reboot add the following to the end of the install.cfg: shutdown I found it in this source file: /usr/src/usr.sbin/sysinstall/dispatch.c This source file has a list of a lot of the functions that can be called in the install.cfg. Even though the function is called shutdown it is a reboot not a shutdown, which is perfect because I wanted it to reboot. I have a local patch that we use on our installation process that adds a couple of new commands: poweroff - shutdown and power off the machine (useful for doing installation, then shut down for shipping) poweroffNoRC - as above, but don't attempt to write rc.conf shutdownNoRC - like regular shutdown (reboot), but no rc.conf The latter two options are handy if you write your own scripts that generate rc.conf, as normally sysinstall tries to write rc.conf itself on shutdown, which clobbers any existing file your scripts may create. If anyone is interested and/or these are likely candidates for inclusion then I can submit a PR to have someone check these in. I also have a man page update that documents the above functions. Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: How can I fix Cannot find file system superblock problem?
On 16/12/2006 6:25 AM, FK wrote: ... But ... I will lose one-month-long-worthing data, which is horrible since I have modified a lot of data for the time. Do I have any practical ways to back up the data without mounting it, given that I could not fix the superblock? Have you tried a Linux Live CD, to see whether or not it can read the disk? I had a drive that FreeBSD choked on trying to mount, yet a Linux Live CD was able to boot and read from the UFS filesystem fine (presumably it only implements the bare essentials to be able to read the UFS filesystem, and perhaps omitted some of the other sanity checks.. It sounds like it would be at least worth while trying... Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: php 5.2.0... go boom!
On 7/12/2006 10:51 PM, Spil Oss wrote: Hi Jonathan, Have you found a solution yet to your segfaulting php 5.2.0? There are reports that it has to do with the order of loading the extensions (notably, session seems to have to be one of the last, and mysql last) Please let me know if it helps (and even if it doesn't) or any other solutions. My php 5.2.0 still won't fly (although the debug-version does!). Have you tried compiling without the SUHOSIN protection patch? This was turned on by default in version 5.1.6_1 of the php5 port, and is on by default in 5.2.0 as well. This patch provides a number of additional security enhancements to PHP, and (I believe) some of these include attempting prevent buffer overflows in PHP itself being affected. Perhaps one of the modules is triggering this and the patch causes the current process to terminate as a safety measure. --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSDStats Report for December 1st, 2006
On 7/12/2006 12:26 AM, Ian Smith wrote: Ahem, could it be someone from (this time) Australia is gaming the system? We've gone up from 425 a little earlier to (just now) 555 FreeBSD systems, and while we're never sorry to be beating the Yanks, especially at their own game, I doubt that it's fair dinkum, mate :) As Marc said, that would be my doing... there's still a few more to come too! Besides, it's good to see Australia on top (where it belongs)... ;-) Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSDStats Report for December 1st, 2006
On 5/12/2006 2:47 AM, hal wrote: On Dec 3, 2006, at 9:43 AM, Boris Samorodov wrote: On Sun, 03 Dec 2006 04:09:18 -0400 Marc G. Fournier wrote: Since the point of this is to be run monthly, out of periodic monthly, the 1st of the month is when all hosts should be 'renewing' their information ... I have some diskless workstations running FreeBSD. Sure users are not supposed to use them _every_ first day of month (ex. when this day is a weekend or a holiday). Whould stats from those workstations be useless? How do machines report in? I have several FreeBSD boxes most of which have non-routable addresses and are behind a firewall. Can I have a spokesman box which reports for all? If I can how? The machines use simple HTTP requests using the 'fetch' program.. if the machines have Internet access via NAT, then that should be sufficient. If they live on a closed network without Internet access, but you have an internal-facing server that does have Internet access, I have a draft document on setting up Apache on that server to forward proxy to the main BSDstats site. It will be posted to the BSDstats site once I've finished it (probably in about a week). If you want to help test the draft instructions prior to publishing, email me privately and I'll provide you with the relevant details. Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (repost) cannot read windows share
On 5/12/2006 5:28 PM, 张韡武 wrote: 在 2006-12-04一的 21:54 -0800，Garrett Cooper写道： Also, I'm not sure if FreeBSD has been configured to run the particular character set you need (nor am I sure where any documentation may be regarding how to set that up), but you also want to explore getting that solved in tandem with the mount_smbfs item. I read carefully with mount_smbfs and as far as I can tell mount_smbfs is using iconv lib which compiled as kernel module. After I run mount_smbfs I checked and made sure libiconv.ko is automatically loaded. According to documents, mount_smbfs automatically load this kernel ... I don't know if this is at all useful, but I have come across the following patches, which appear to have been ported from Darwin, to improve handling of multibyte character sets: http://people.freebsd.org/~imura/kiconv/ It would be interesting to see these committed (if they are valuable), as I know there are issues with FreeBSD mount_smbfs when operating against the Mac OSX samba implementation, which (I am told) only speaks UCS2. Given the work already gone into these, it would be nice to see them finished off and committed... I wonder how many other smbfs-related improvements may exist in Darwin that might be worth looking at? http://www.opensource.apple.com/darwinsource/10.4.8.x86/smb-217.18/ Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: (repost) cannot read windows share
On 5/12/2006 5:56 PM, 张韡武 wrote: 在 2006-12-05二的 17:36 +1100，Antony Mawer写道： [snip] I don't know if this is at all useful, but I have come across the following patches, which appear to have been ported from Darwin, to improve handling of multibyte character sets: http://people.freebsd.org/~imura/kiconv/ It would be interesting to see these committed (if they are valuable), as I know there are issues with FreeBSD mount_smbfs when operating against the Mac OSX samba implementation, which (I am told) only speaks UCS2. ... But I think FreeBSD-6.1 do not include this nice person's work! Thus even mount_smbfs -E UTF-16:GB2312 won't work for me. No current versions of FreeBSD include the patches at the above site - my understanding is that they may still require some work before they are ready for committing. I've CC'd R. Imura (who produced the patches) who may be able to answer the question (as well as possibly help you with your issue). Now I am really interested if I can get smbmount (part of samba) working, if so, problem solved, otherwise there is no way to go. I believe smbmount is Linux-specific, so I think your best chance is trying to get the patches mentioned above finalised for your use. Regards Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: image based stock spam
On 13/11/2006 12:00 PM, Brian wrote: Looks like the preferred approach many folks re the above problem is fuzzyocr? Since there isn't a port for that, is there another FreeBSD solution worth mentioning here? http://www.freshports.org/mail/p5-FuzzyOcr/ --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ethernet port bondage
On 2/11/2006 9:10 AM, Dan Nelson wrote: In the last episode (Nov 01), Kenny Dail said: I'm running 6.1 Release, and I've been looking for information on how to bond multiple ethernet adaptors in one box so that if one card or connection fails or is disconnected I still have network connectivity. Have a look at carp(4). It's a failover solution and not a bonding one, but it sounds like that's more what you're after anyway. Thanks for that, but I would be interested in bonding, unless in the FreeBSD world that can't be achieved with failover. It's a fairly straight forward setup on my Linux servers, I was thinking it would be easy enough, but I haven't seen the docs for it anywhere. Try ng_fec, although it really doesn't implement fec negotiation, so you need to hardcode the settings to match on the switch. There's also ng_one2many. I posted instructions a while ago on how to setup ng_fec along with an HP ProCurve switch supporting FastEtherchannel -- the same should also apply for Cisco switches. Be warned that newer HP/Cisco gear has dropped support for FEC in favour of 802.3ad/LACP... http://lists.freebsd.org/pipermail/freebsd-net/2006-September/011901.html I haven't experimented with ng_one2many, but my understanding is that it only provides a dumb balancing/bonding solution. Presumably we need an ng_bonding or something along those lines would be required to achieve parity with what Linux can provide...? --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: smbfs rsync
On 19/10/2006 4:35 AM, Vahan Yerkanian wrote: Greetings, On one of my machines running 6.1-RELEASE rsync over a smbfs share is failing with the following error: building file list ... rsync: readdir(/ipa1/tmimage/2001): Bad file descriptor (9) done IO error encountered -- skipping file deletion sent 246047 bytes received 20 bytes 492134.00 bytes/sec total size is 3876995600 speedup is 15755.85 rsync error: some files could not be transferred (code 23) at main.c(892) [sender=2.6.8] where /ipa1 is a smbfs share. I've googled and found this [1] particular article that pinpoints a simple coding mistake, anyone knows if this is going to be fixed in 6.2-RELEASE? /usr/sbin/mount_smbfs is the binary affected, [1] http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/78953 You're on the right track with the PR, and Jim Carroll did the hard work of coming up with a patch for the issue. Unfortunately I haven't had the chance to test the patch, but will try and make time to... I'd imagine this is probably too late to get into 6.2 (any dev's care to comment?), but if we're able to test + verify it works then I don't see why it shouldn't make 6.3. SMBFS could still use a bit of polish in areas... there are also UCS2 patches outstanding that would make talking to MacOSX servers much more pleasant: http://people.freebsd.org/~imura/kiconv/ Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AHCI support in 6.1-RELEASE?
On 10/10/2006 10:18 AM, Juha Saarinen wrote: Hmm... ata-chipset.c says there is AHCI support. #include sys/cdefs.h __FBSDID($FreeBSD: src/sys/dev/ata/ata-chipset.c,v 1.126.2.11 2006/03/16 21:28: 51 sos Exp $); If so, what could be the reason for FreeBSD not finding the SATA hard disk in the system in AHCI mode? Most likely this renumbers the drivers, so you go from your hard drive showing as eg. ad0 to ad4. You will need to edit /etc/fstab as appropriate to match what the drive is showing up as after changing to AHCI mode. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: AHCI support in 6.1-RELEASE?
On 10/10/2006 11:02 AM, Juha Saarinen wrote: On 10/10/06, Antony Mawer [EMAIL PROTECTED] wrote: Most likely this renumbers the drivers, so you go from your hard drive showing as eg. ad0 to ad4. You will need to edit /etc/fstab as appropriate to match what the drive is showing up as after changing to AHCI mode. Yep... exactly like that - from ad0 to ad4. Worked perfectly. Thank you very much, it didn't occur to me that there would be driver renumbering when switching to AHCI. Oddly enough, even though the drive is connected to SATA port 0 on the motherboard, it shows up as being on ATA channel 2, Master. According to atacontrol, I have six ATA channels on the box, 0-5. Doesn't seem quite logical that the driver should be renumbered as ad4, but... if it works, I don't care. Usually I find that ad0/ad1 = primary IDE (master/slave), ad2/3 = secondary IDE (master/slave), and then the SATA connectors pick up from ad4 onwards... The SATA ports seem to be numbered in increments of 2, presumably because every SATA port is a master, so the usual slave position is unused... ie: SATA 0 - ad4 SATA 1 - ad6 SATA 2 - ad8 SATA 3 - ad10 Presumably turning off ATA_STATIC_ID would just number them in the sequential order (ad0, ad1, ad2, ...) based on the devices that are actually connected... but this can mess things up when you connect additional drives at a later date somewhere in the middle of the chain! I have a patch I wrote for sysinstall somewhere that allows you to do disk=auto in an install.cfg, and it picks the first device it comes across (eg. if ad4 is the first IDE disk, it picks it over ad10)... we've found this very handy for installation/deployment scenarios that are automated via install.cfg but may have different disk configurations... If there's enough interest I might look at submitting it for inclusion... Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Removing removable ATA hard drives
On 5/10/2006 7:31 PM, Jonathan McKeown wrote: I should probably have said: we don't currently have offsite backups (we've exceeded the capacity of our tape device and our budget), and the quick-fix solution is dumping to this hard drive and then pulling it out and taking it home. As such the removability is key to its intended function. I can't keep dropping the main fileserver to fiddle with it, and the alternative in terms of testing is to set up another box with the particular 4.9-STABLE snapshot running on this server (to eliminate OS version-related variable effects). I looked into these options, and in the end opted for an external firewire hard drive for *ONE* of my offsite backup systems. I initially looked at USB, but found it to be somewhat flakey and didn't feel comfortable relying on it. I installed a firewire add-in card in the backup server, and am then using GELI to encrypt the data on the drive. I have a script which automates the attaching to the geli volume, mounting the filesystem, rsyncing from various sources, and then unmounting the filesystem... after which I can turn off the drive and take it offsite with me. This is on FreeBSD 6.1, so I don't know what, if any, firewire support is available on 4.x... ATA hotswap, from what I gather, is only possible with specific hardware support, and even then is not something that it was originally designed for (as far as I am aware)... Hope you or others find some of this helpful! --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSDStats v4.0: Attempt to address some major issues ...
On 29/09/2006 1:11 AM, Joao Barros wrote: On another subject, with the addition of the other BSDs the releases stats for example are pretty much nonsense. Do you plan to work on that? Yep, each individual *BSD is getting its own detailed stats summary section... they're not finished yet, so at the moment I've left the links to the old (nonsensical) pages, but it's a long weekend here this weekend so I'm hoping to try and finalise them :-) See here for the FreeBSD page: http://www.bsdstats.org/freebsd/ Thus far I have Releases and Countries done, so it's just a matter of some further formatting and then the Platforms + Devices pages... Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSDStats v4.0: Attempt to address some major issues ...
On 29/09/2006 2:01 AM, Erik Norgaard wrote: Matthew Seaman wrote: On the other hand, the duplicates could be the result of people deliberately trying to frig the statistics or just innocently running the 300.statistics script manually several times. In either case, entries with duplicate tokens should be discarded -- I guess you'ld always want to keep just the last entry for any token. How is the country determined? by whois lookup? I am just surprised that after the wipe and required update of the stats-script, Panama has 75% of the hosts, 10 times the US. Via the GeoIP module. Marc's servers are mostly/all located in Panama (hub.org), hence why they're in there quickly after the stats wipe :-) --Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD not popular in Asia?
On 8/09/2006 8:43 PM, Norberto Meijome wrote: On Fri, 08 Sep 2006 21:18:44 -0400 Dan Langille [EMAIL PROTECTED] wrote: Check out http://www.bsdstats.org ... Republic of Korea is about to push the US out of first place, but there are *zero* FreeBSD boxes reporting from there ... DragonFly is first, then NetBSD and then OpenBSD ... Are there *really* no Korean FreeBSD hosts out there ... ? Correct. There are no Korean FreeBSD hosts out there... that have signed up. I have about 8 or 10 boxes, I've signed up only one. No particular reason. somewhat similar... i've got boxes here in AU which, for a reason or other, haven't added. That issue has been addressed... us Aussies should start showing up as of next month's results (or re-run the submission manually if you can't wait :-). It was a timezone difference issue. Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD not popular in Asia?
On 8/09/2006 3:02 PM, Marc G. Fournier wrote: Check out http://www.bsdstats.org ... Republic of Korea is about to push the US out of first place, but there are *zero* FreeBSD boxes reporting from there ... DragonFly is first, then NetBSD and then OpenBSD ... Are there *really* no Korean FreeBSD hosts out there ... ? Are you sure they weren't just hit by the same timezone issue affecting us Aussies...? :-) After all, DFly/Open/Net didn't start coming on board until after the monthly rollover that affected us in .au ... (For those wondering what all that means: the BSDstats server counted .au and nearby timezones into August's results, rather than September, because the BSDStats server's time was still in August when our machines started doing our monthly periodic run for September...) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSDstats Project v2.0 ...
On 8/08/2006 1:56 PM, David Schulz wrote: Ok i love the Idea of this, and will have all my machines running that in no time. Just make the Site look more sleek :) I will be hopefully the first one representing China on that list as well (brag :-) I'm working on it -- unfortunately have been very busy the past few days but hope to have something ready within the next couple of days. Patience... :-) Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSDstats Project v2.0 ...
On 9/08/2006 9:16 AM, Marc G. Fournier wrote: Can you tell me exactly what you do with those two pieces of data? Is there any way that information would be accessible from the internet? Absolutely nothing else we do with it ... it just gives us a unique key to work with ... in fact, assuming each of your servers use a different IP, there is no reason you couldn't do the uname trick above to hide the hostname ... Unless someone breaks into the server, or database, somehow, the data isn't accessible ... What if we improved upon this - if instead of storing the hostname and IP address, we stored a one-way hash of this information? OpenSSH in recent versions takes the same approach with its authorized_keys files... -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSDstats Project v2.0 ...
On 9/08/2006 1:49 PM, Marc G. Fournier wrote: On Tue, 8 Aug 2006, Nikolas Britton wrote: PCBSD# uname -a FreeBSD PCBSD.localhost 6.1-RELEASE-p2 FreeBSD 6.1-RELEASE-p2 #0: Fri Jun 16 09:21:34 PDT 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PCBSDv1.11 i386 Unfortunately, if they are *all* the same hostname, and behind NAT, they will just be seen as *one* host ... what is PCBSD? It's a user-friendly version of FreeBSD designed to provide a workstation environment for the more novice-style users.. see here for details: http://www.pcbsd.org/?p=learnhome It's not a different BSD OS per se (as opposed to Free/Dragonfly/Net/OpenBSD) but obviously the pre-defined hostname is a problem for determining uniqueness... I wonder if this is something better addressed by the PC-BSD developers as part of their setup process? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: BSDstats Project v2.0 ...
On 8/08/2006 7:17 AM, Chris wrote: After the install, better documentation might be add. Meaning, it needs to be defined that the 2 lines To enable the port, edit or create /etc/periodic.conf and add this line: monthly_statistics_enable=yes To enable device reporting, add this line: monthly_statistics_report_devices=yes Why not tackle this in a similar manner to the Postfix port - after installing (provided we're not in a non-interactive build), we prompt: Do you wish to activate stats reporting in /etc/periodic.conf [n]? y Do you wish to report your installed hardware? Would you like to submit your systems stats now? or something along those lines. This would make it much easier than people installing the port and neglecting to set the appropriate lines, effectively achieving nil ;-) -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stand up and be counted - BSDStats Project
On 4/08/2006 3:17 AM, User Freebsd wrote: On Fri, 4 Aug 2006, Matthew Seaman wrote: This is cool and all, but why are the concentration solely on PCI devices? pciconf output doesn't tell you directly what CPUs are in the system or even how many there are. It doesn't tell you exactly what sort of memory or disk drives the system uses -- all of which would be important information that might just persuade hardware manufacturers to provide more FreeBSD support. Surely a condensed version of /var/run/dmesg.boot is more to the point. /var/run/dmesg.boot can't be relied on, unfortunately ... I've had *many* times where a reboot leaves that blank, or with non-dmesg like output ... if you can provide a non-dmesg method of adding this information that is consistent (ie. pciconf), then sure, we can add this sort of information ... Some of this information can be gathered from the hw.* sysctl's, at least on 6.x... -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 3/08/2006 2:25 PM, User Freebsd wrote: b. Duplicates. Ted seems to have this covered with the CPU ID thing ... Isn't this one of those things that BIOS vendors added a Disable flag to their BIOS setup's for in order to prevent the wide-spread privacy concerns that cropped up when it was first released? I'm fairly sure this is disabled on most of the systems I've built... The token-based system mentioned by Mikhail Goriachev sounded interesting, although I haven't done any further thinking past what was originally mentioned... c. Fakery. IMHO, not a *really* big issue ... I could see someone bothering to do it once or twice, but seems to be alot of work for little gain ... Agreed... I could probably add around 1,500 systems that could conceivably be setup to chime in with their numbers periodically; one of the pre-requisites for that would be that the access method be HTTP or HTTPS based so it could be relayed via a proxy... Another nice thing to include might be a hash of hardware inventory (a further opt-in thing beyond the basic checkins)... Mark alluded to this early in the piece, but it would be nice to be able to pull up something that said hang on, out of the X% of users on file, Y% are using Adaptec SCSI cards, in particular model XYZ... this would be very helpful when trying to get vendor support etc... Some form of hash calculated on these would allow you to detect if they had changed at all, and only re-send them in the event of a change... ... just thinking out loud ... ! -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 4/08/2006 4:58 AM, User Freebsd wrote: Getting a list of devices is actually pretty easy, and I've tried this on my 4.x machines also, so it isn't something that will be a problem on older versions: # pciconf -l [EMAIL PROTECTED]:0:0: class=0x06 card=0x chip=0x700c1022 rev=0x20 hdr=0x00 ... And, more specifically, we can get: # pciconf -l -v [EMAIL PROTECTED]:9:0: class=0x010400 card=0xc0351044 chip=0xa5111044 rev=0x01 hdr=0x00 vendor = 'Adaptec (Formerly: Distributed Processing Technology (DPT))' device = 'Raptor SmartRAID Controller' class= mass storage subclass = RAID All of the expanded 'vendor', 'device', 'class' and 'subclass' information is present in the non -v version of the command output. The numbers shown earlier can be used to derive the text information: class=0x010400 determines the class/subclass lines, using the table from here: http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340 card=0xc0351044 chip=0xa5111044 these make up the vendor and device lines, using the list in /usr/share/misc/pci_vendors (which is derived from the PCIDEVS.TXT listing). The last 4 hex digits of the card and chip lines are the vendor ID while the first 4 are the device ID. The card is often given by the vendor, while the chip identifies the actual part it uses to implement functionality. For instance, a Netcomm ethernet NIC may use a Realtek 8139 chip... so chip gives us the fact it's essentially a generic Realtek chipset, while the card tells us the vendor who manufactured the card perhaps their name for it. In short, there's no reason to have to transmit all the text names back to any server -- this can all be resolved at the server end, So, with that one command, we can get a fair amount of hardware information ... but, how to feed that into a proper HTTP request? Storing all of that information would be cool, cause then we could build reports based on device driver / vendor / device / class and subclass ... but that might be a bit heavy to do in an HTTP request, no? I take it email isn't an option, in your case? Email may be a viable alternative -- one concern with email is that various organisations SMTP servers blast their own disclaimer message and so on across the bottom of all out-going emails, which might complicate parsing of it on the server end. If you're only encoding purely the numeric details, this would make the information far lighter to transmit than having the whole text blurb. Just the pciconf -l version as-is: ~$ pciconf -l|wc -c 1545 So that's ~1500 bytes. Now strip out all the unnecessary text - the class=, card=, chip=, rev=, hdr=, extra spaces... something like: [EMAIL PROTECTED]:5:0: 01 34358086 00301000 08 00 [EMAIL PROTECTED]:5:1: 01 34358086 00301000 08 00 [EMAIL PROTECTED]:4:0: 02 10798086 10798086 03 00 [EMAIL PROTECTED]:4:1: 02 10798086 10798086 03 00 ~$ cat pciconf-stripped | wc -c 899 We've nearly halved the size of the information. Now it's still in ASCII, so you could further shave bits off by converting that to binary if you wanted to... With that amount of information, you'd probably be more inclined to want to use HTTP POST than HTTP GET. A quick glance suggests libfetch(3) doesn't support this; I haven't looked at the code enough to see if adding support for it would be trivial or not. -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stand up and be counted - BSDStats Project
On 4/08/2006 7:30 AM, User Freebsd wrote: ... STEP 2: pciconf -lv needs to be parsed, this being the hard step, into a string that can be sent via HTTP ... this is the hard part because it has to be done as/in a shell script ... anyone out there *really* good at shell programming? See my comment in the other thread -- you don't need any of the text details, all yo uneed are teh class/card/chip/rev/hdr fields. The bits before it would be helpful to identify what drivers are attached on different versions (and also to see what drivers people disable vs leave enabled for bits of their hardware). Optimally, we'd love to have everyone report pciconf information, since knowing what vendors and devices are in use would definitely add more weight then *just* what version of FreeBSD, but in order to hopefully get as much buy into this as possible, the script should be written to allow it to be disabled ... again, I can't think of why someone would feel that that was 'sensitive information', but providing the option to shut it off is definitely a must ... Agreed - if someone wants to stand up and be counted, but they feel details of their hardware choices to be a gross violation of their personal privacy, then we shouldn't put that in their way as a barrier to adoption. -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 4/08/2006 10:29 AM, User Freebsd wrote: I was thinking of that ... my concern, and it may be totally invalid, but is it guaranteed to always translate the same? ie: ... Will that always translate the same regardless of running 4.x vs 5.x vs ... ? If so, you are right, that does greatly simplify things ... I just wasn't 100% certain ... The text may change slightly, but if anything, wouldn't it be better if all your stats consistently referred to the same device IDs with the same strings? A vendor name may be updated in the list (company gets bought out, renamed, etc), but I'm fairly sure nothing ever gets *removed* from the list - it just grows as new devices and vendors are added over time. The important information is the ID numbers -- the text attached to them will always be the same in meaning, even if the text may vary a few letters here or there (ie. a device ID that was a Pro/1000 NIC won't suddenly turn into a Realtek 8139 one day). The non-verbose information is all you need for building a stats database. Your stats database can have its own database of the pcidevs.txt imported periodically, and link the information up at display time. -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stand up and be counted - BSDStats Project
On 4/08/2006 10:38 AM, Tamouh H. wrote: I've been doing some thinking on it this afternoon, and think I've figured out about the simpliest way of doing it ... it still doesn't deal with fakers and such, but, IMHO, I don't think that that is a *huge* problem that needs to be addressed ... some might do it for a lark, but, overall, it just sounds like something that is more worth then its worth, so over time, it should eventually balance out ... Excellent idea, and will be one of first to register! I don't believe at first it is that important to ensure no fake entries, it is more crucial to get this project started at first then deal with the more troublesome details. The best approach is probably to start out with a v1 as an experiment - get interested parties involved, start testing, evaluate your results, modify as necessary... ... once you have something that's been proven on a smaller scale, you can look to expand the scope and get more wide-spread usage. -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 4/08/2006 11:44 AM, Nikolas Britton wrote: 899 bytes * (10^7) = 8.37258995 gigabytes... Remember... Once this code is pushed out to hosts you can't change it. 10 years from now we'll still have hosts sending in old data What was wrong with my netcat idea? uname -mr | nc statistics.freebsd.org 1234 It's one, short, line of code and you know exactly what it's doing. Simple, Easy, Done. Part of the idea I mentioned earlier was using a hash of this information... so the first time you send it through, you generate a hash and store it... then in future you can iterate over the hardware list, hash it, compare it against your stored hash, and only send if the hardware inventory has changed... Not everywhere has unrestricted access out to the Internet via whatever port they want... I know of many sites that only allow HTTP, and only via a proxy... I guess there's two different goals here... the uname -mr gives vendors an idea of what install base is out there when they're considering developing drivers/platform support... the hardware inventory gives vendors, developers and users an idea of what existing hardware is in use... ... if someone could bring up a list and find out that 500,000 people were using such-and-such a driver, it may influence the decision as to whether or not to update said driver when architectural changes are being made that require updates to the drivers... instead of the current system of sending an email out and hoping the appropriate users spot it on the appropriate mailing list and pipe up... -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gotta start somewhere ... how many of us are really out there?
On 4/08/2006 1:31 PM, User Freebsd wrote:
'k, looking at the above, and comparing it to what I'm getting from
pciconf -l, I'm missing something ... namely:
[EMAIL PROTECTED]:10:0:class=0x02 card=0x0027a0a0 chip=0x813910ec
rev=0x10 hdr=0x00
Translates to:
[EMAIL PROTECTED]:10:0:class=0x02 card=0x0027a0a0 chip=0x813910ec
rev=0x10 hdr=0x00
vendor = 'Realtek Semiconductor'
device = 'RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter'
class= network
subclass = ethernet
But, the last 4 hex of card/chip aren't teh same ... oh, wait,
re-reading what you stated, is it safe to assume that chip= can be
ignored ... nope, that doesn't follow either ... but I think I see it ...
Looking through src/usr.sbin/pciconf/pciconf.c, it looks as though
pciconf only translates the chip= for what it displays. The DOS-based
PCI identification code that I've worked with in the past typically
referred chip as device, and card as sub-device... Internally,
pciconf uses the same references (snipped from the printf statement):
(p-pc_subdevice 16) | p-pc_subvendor,
(p-pc_device 16) | p-pc_vendor,
The aforementioned DOS utilities used to display lookups for both (where
appropriate); I vaguely recall coming to the conclusion that the
sub-device bit was not mandatory, but someone with more knowledge of the
ins and outs of the PCI specs may be able to state that more definitively...
In short, the chip field from pciconf looks like the most important
one.. the rev/hdr fields are less important for our needs - as far as
I'm aware they're generally used to denominate hardware revisions, so as
vendors revise their PCB layouts and components, they can be easily
differentiate between them -- this is most important when you're a
driver, trying to figure out what how you should treat a specific
device... The card one may fall into a nice-to-know but not necessary..
For the above, vendor *should* be Aopen Inc, not Realtek Semiconductor ...
'k, so, for the above:
card=0x0027a0a0
- Aopen Inc (A0A0)
chip=0x813910ec
- Realtek Semiconductor (10EC)
- 8139RT8139 (A/B/C/810x/813x/C+) Fast Ethernet Adapter (8139)
And the 0027 is actually meaningless in this case ...
So in your case, it's a Realtek 8139 adapter, most likely as part of an
AOpen motherboard or add-in card...
So, what I'm looking for is vendor-device, but in some card= cases,
there won't be a 'Device' listed ...
As to class= ... what table am I supposed to be seeing at that URL?
The class= line is a combination of two fields (the same as chip and
card are a combination of vendor and device fields) -- the class, and
subclass, of the device.
The URL http://fxr.watson.org/fxr/source/dev/pci/pci.c#L1340 shows the C
source for this table that's used to match them up... for instance:
CLASS SUBCLASSDESCRIPTION
{PCIC_NETWORK, -1, network},
{PCIC_NETWORK, PCIS_NETWORK_ETHERNET, ethernet},
{PCIC_NETWORK, PCIS_NETWORK_TOKENRING, token ring},
{PCIC_NETWORK, PCIS_NETWORK_FDDI, fddi},
{PCIC_NETWORK, PCIS_NETWORK_ATM, ATM},
{PCIC_NETWORK, PCIS_NETWORK_ISDN, ISDN},
The first line of the above defines the network device class; then it
defines several of the sub-classes of class network... ethernet, token
ring, etc. These are defined here:
http://fxr.watson.org/fxr/source/dev/pci/pcireg.h#L218
So this line:
{PCIC_NETWORK, PCIS_NETWORK_ETHERNET, ethernet},
actually reads:
{0x02, 0x00, ethernet},
So our class line:
class=0x02
Is made up of 2 hex digits for the device class, and 4 hex digits for
the device sub-class...
Savvy? ;-)
-Antony
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.1 rl interface
On 8/07/2006 5:10 PM, Rob Hurle wrote: But the killer is that I want to run 2 ethernet interfaces. The on-board one is fxp0 (Intel) and comes up fine. The other is a PCI card with the RealTek 8139D chipset, so I'm expecting a rl0 interface. I've put if_rl_load=YES into the /boot/loader.conf filem but the system does not seem to like it, giving me the message failed to register: 17 at module load time, and then no driver attached at bring-up-interface time. /var/log/messages extract is as follows: ... Jul 9 09:14:08 grandpa kernel: module_register: module pci/rl already exists! Jul 9 09:14:08 grandpa kernel: Module pci/rl failed to register: 17 This means the driver is already in the kernel, so you do not need to load it manually by placing the if_rl_load=YES line in your loader.conf. Jul 9 09:14:08 grandpa kernel: pcib5: ACPI PCI-PCI bridge at device 30.0 on pci0 Jul 9 09:14:08 grandpa kernel: pci5: ACPI PCI bus on pcib5 Jul 9 09:14:08 grandpa kernel: pci5: network, ethernet at device 2.0 (no driver attached) So the network card is found, but the rl driver doesn't detect that it's a Realtek NIC and bind to it. It may simply be a case of having to add the appropriate PCI device IDs to the driver. Could you provide the output of pciconf -lv? (what is plip0 - did not occur on FreeBSD 4.6?) This is the IP-over-parallel port interface; unless you're using a network connection over the parallel port you can usually disable this. Regards Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 compat with DL320 G4
On 6/07/2006 4:26 PM, William wrote: Server got here, FreeBSD 6.1 went on easy as you like and then I installed the intel card when it got here... I havent had to recompile a thing and its detected the card fine. I've appied an IP address, cvsup/install a few ports without any issues.. dmesg goodness: em0: Intel(R) PRO/1000 Network Connection Version - 3.2.18 port 0x4000-0x401f mem 0xfdee-0xfdef,0xfdec-0xfded irq 16 at device 0.0 on pci2 em0: Ethernet address: 00:15:17:0b:e6:18 em1: Intel(R) PRO/1000 Network Connection Version - 3.2.18 port 0x4020-0x403f mem 0xfdea-0xfdeb,0xfde8-0xfde9 irq 17 at device 0.1 on pci2 em1: Ethernet address: 00:15:17:0b:e6:19 Should I grab the latest copy of the driver (off intel's website) and recompile anyway? It sounds like you were lucky with your card -- we tried a 6.1 installation and it did not detect our Intel Pro/1000PT card, while the 7-CURRENT driver did. A back-port of the 7-CURRENT driver looked relatively non-trivial, but the Intel driver for 6.x saved the day. If it's all working properly, then you should be right to continue with the 6.1 driver you are currently using. If it ain't broke, don't fix it! Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 compat with DL320 G4
On 29/06/2006 9:27 PM, Erik Trulsson wrote: On Fri, Jun 30, 2006 at 07:56:00AM +0100, William wrote: Antony, I've got an Intel card in production already on a homebrew box, the code is INTEL-PWLA8492MT and description is Intel Dual Port Server Adapter 10/100/1000. Any idea if that will do? That is a PRO/1000 MT card, which is a PCI-X adapter and is supported by the standard em(4) driver in FreeBSD 6.x, The PRO/1000 PT mentioned below is a PCI-Express adapter and is not supported by the standard driver in 6.x, but (as mentioned) should be supported by the driver available from Intel. If you wish to utilise the PCI Express expansion slots by using a Pro/1000 PT network adapter, the procedure to follow might be something like be this: 1. Install 6.1-RELEASE from CD, being sure to install the kernel source 2. Obtain the latest Intel driver for FreeBSD 6.x (if it is still not available on the website, email me and I will send it to you) 3. Burn the driver onto a CD or other media and copy it onto the server 4. Extract the driver source, and copy the if_em* files across into /usr/src/sys/dev/em/ 5. Build a new kernel (GENERIC will suffice) which will utilise the new driver source (cd /usr/src make buildkernel) 6. Install the kernel and reboot (make installkernel) You should now have a working network with your Pro/1000 PT... Regards Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 compat with DL320 G4
On 30/06/2006 3:53 PM, William wrote: Thanks for the email Antony, I'm awaiting delivery of the server so I might have to order an intel card sharpish. What can I do the server+fbsd 6.x to prove the lock up? Regards, Will Configure the network card (bge0) and then do something to pass traffic across the network (eg. ping another host on the network). In our case, the machine booting at startup and the various network services starting up was enough to do it within seconds. I have a copy of the Intel driver we used if you are looking to run this machine on FreeBSD 6.0 or 6.1; the standard driver in these releases will not support the Pro/1000 PT (at least the card we used). Regards Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 compat with DL320 G4
On 30/06/2006 4:56 PM, William wrote: I've got an Intel card in production already on a homebrew box, the code is INTEL-PWLA8492MT and description is Intel Dual Port Server Adapter 10/100/1000. Any idea if that will do? The adapter you mentioned is a PCI-X adapter, which won't work unless you purchase the optional PCI-X riser card to replace the standard one in the DL320 G4. The standard riser card provides PCI Express slots (1 half height, 1 full height), that are not compatible with PCI-X (or regular PCI). You will need to either: 1) Purchase the PCI-X riser, and then use your existing card (provided that FreeBSD 6.x will recognise it) 2) Purchase a PCI Express NIC, which will (likely) _not_ work with the standard driver in 6.x. Option 1 may or may not work with the standard 6.x driver; I know the PCI Express one definately does NOT. That being said, it is _very_ simple to add the updated Intel driver and rebuild the kernel if you need to do so (for either option): I'd be happy to help you with the steps you need to do so if you require. Regards Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 6.0 compat with DL320 G4
On 23/06/2006 6:24 PM, Ted Mittelstaedt wrote: Out of the box the DL 320 G4 ships with a riser card that has 2 pci express slots. At least that is what they are supposed to be, we haven't tried them. ... If you only do the pci express then the adapter you want is the Intel Pro 1000 PT either the single port or the dual port, and make sure it is the server adapter not the desktop adapter (the models carry the same model number but different descriptions, which is infuriating) We ended up in this same situation, and went down the Intel PCI express NIC path (Intel Pro/1000PT). Be advised that, at this stage, the driver in both 6.0 and 6.1 -RELEASE does not support this card, but support is present in 7-CURRENT. That being said, with the official Intel driver (v6.0.5, not sure if it's released yet), I was able to replace the standard em driver in 6.0, build a new kernel, and bring the server up and survive some pre-deployment load testing without any hiccups. Be aware that while the riser card has two PCI Express slots, one is half-height, and the Intel NICs (at least the one we received) are a full card. The onboard Broadcom NICs weren't worth the PCBs they were printed on in terms of stability -- we were seeing the same hard lockups as Ted and didn't have the luxury of time to spend fiddling with it!! From what I gather from Ted's previous investigations, there's various work-arounds in the Linux driver that work around some shortcomings in the hardware itself... Regards Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: One hour offset with smbfs
On 31/12/2005 10:16 AM, Gilbert Cao wrote: I just ran into a small problem with modification time with smbfs : My smb client machine is a FreeBSD 6.0 with GMT+1. My smb server machine is a FreeBSD 5.4 with also GMT+1. I have noticed a one hour offset between a file's modification time when I `ls -l file` from the smb client machine and the same file's modification time when I `ls -l file` from the smb server machine. That file stands in a smb shared directory, on the smb server. More, I have noticed this, only for a datetime like 1st April, 2005. For a datetime like 1st December 2005, the problem does not occur. For example, from the smb client side, I see a modification time of 2005-04-01 00:00:00, and from the smb server side, I see a modification time of 2005-03-31 23:00:00. When I do a `touch -t 20050401.00 file` from the smb server side, I see 2005-04-01 01:00:00, from the smb client side. When I do a `touch -t 20050401.00 file` from the smb client side, I see 2005-03-31 23:00:00, from the smb server side. It seems that it is only a matter with summer time. Anyone know if something can be done about this ? I guess the problem is on the smbfs client side ... This appears to be a problem with smbfs when dealing with timestamps in daylight savings time (or summer time, as you refer to it). I looked into it briefly, and from what I read it seems the kernel is divorced of knowing anything about daylight savings time (only a boolean value indicating whether or not it is currently daylight savings or not is maintained). This means when times from the SMB server are translated, the kernel can't adjust the date/time stamps to compensate for the DST offset, as it doesn't know what the offset is... (not everwhere uses an hour difference for DST) I'd love for someone to correct me and tell me that there's an easy way to fix this issue -- this was just my deduction after a brief look into the matter. Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Adding lines to /etc/rc.conf during sysinstall wihout being REMOVED
On 17/12/2005 4:22 AM, Josh Endries wrote:
Does anyone know the correct way to add lines to rc.conf without
sysinstall commenting them out and prepending REMOVED to them,
during an automated install.cfg routine? Currently I have a pkg I
made that adds stuff like ntp.conf and rc.conf, but all the lines in
my custom rc.conf are removed after the script finishes.
I looked through the code for sysinstall but didn't see any way to
disable this behavior (my C isn't very good). What would be the
correct way to do this? I'm now having my pkg install a rc.d script
which cat's /etc/rc.conf...
I hit this same problem in building a custom installation disc, and
wound up extending sysinstall to have a shutdownNoRC that would function
the same as the shutdown statement in an install.cfg, only without
touching the rc.conf. This was useful for us, as we installed a custom
rc.conf and did not want sysinstall to touch it.
I also added a poweroff and poweroffNoRC methods that function the
same as the shutdown statement, only power off the machine instead.
This can be quite handy in a production line environment, when used in
conjunction with the cdcontrol(1) command to eject the CD, prior to
powering off the completed system.
I've attached the patch if anyone is interested... perhaps if there is
sufficient interest then someone could see about getting this committed.
The attached patch is against 6.0-RELEASE.
Regards
Antony
Index: usr.sbin/sysinstall/dispatch.c
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/dispatch.c,v
retrieving revision 1.47
diff -u -r1.47 dispatch.c
--- usr.sbin/sysinstall/dispatch.c 30 Aug 2004 21:03:09 - 1.47
+++ usr.sbin/sysinstall/dispatch.c 18 Nov 2005 02:11:20 -
@@ -43,6 +43,9 @@
#include list.h
static int dispatch_shutdown(dialogMenuItem *unused);
+static int dispatch_shutdown_norc(dialogMenuItem *unused);
+static int dispatch_poweroff(dialogMenuItem *unused);
+static int dispatch_poweroff_norc(dialogMenuItem *unused);
static int dispatch_systemExecute(dialogMenuItem *unused);
static int dispatch_msgConfirm(dialogMenuItem *unused);
static int dispatch_mediaClose(dialogMenuItem *unused);
@@ -111,6 +114,9 @@
{ addGroup, userAddGroup},
{ addUser, userAddUser },
{ shutdown, dispatch_shutdown },
+{ shutdownNoRC, dispatch_shutdown_norc },
+{ poweroff, dispatch_poweroff },
+{ poweroffNoRC, dispatch_poweroff_norc },
{ system,dispatch_systemExecute },
{ dumpVariables, dump_variables },
{ tcpMenuSelect, tcpMenuSelect },
@@ -178,6 +184,27 @@
}
static int
+dispatch_shutdown_norc(dialogMenuItem *unused)
+{
+systemShutdownNow(0, SHUTDOWN_NO_RC_CONF);
+return DITEM_FAILURE;
+}
+
+static int
+dispatch_poweroff(dialogMenuItem *unused)
+{
+systemShutdownNow(0, SHUTDOWN_POWEROFF);
+return DITEM_FAILURE;
+}
+
+static int
+dispatch_poweroff_norc(dialogMenuItem *unused)
+{
+systemShutdownNow(0, SHUTDOWN_POWEROFF | SHUTDOWN_NO_RC_CONF);
+return DITEM_FAILURE;
+}
+
+static int
dispatch_systemExecute(dialogMenuItem *unused)
{
char *cmd = variable_get(VAR_COMMAND);
Index: usr.sbin/sysinstall/sysinstall.8
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.8,v
retrieving revision 1.69.2.1
diff -u -r1.69.2.1 sysinstall.8
--- usr.sbin/sysinstall/sysinstall.89 Oct 2005 03:48:42 - 1.69.2.1
+++ usr.sbin/sysinstall/sysinstall.818 Nov 2005 01:55:58 -
@@ -813,6 +813,26 @@
.Pp
.Sy Variables :
None
+.It shutdownNoRC
+Stop the script and terminate sysinstall, but do not touch
+.Pa /etc/rc.conf .
+.Pp
+.Sy Variables :
+None
+.It poweroff
+The same as
+.Pa shutdown ,
+only power off the system (if possible) rather than rebooting.
+.Pp
+.Sy Variables :
+None
+.It poweroffNoRC
+The same as
+.Pa shutdownNoRC ,
+only power off the system (if possible) rather than rebooting.
+.Pp
+.Sy Variables :
+None
.It system
Execute an arbitrary command with
.Xr system 3
Index: usr.sbin/sysinstall/sysinstall.h
===
RCS file: /home/ncvs/src/usr.sbin/sysinstall/sysinstall.h,v
retrieving revision 1.264.2.1
diff -u -r1.264.2.1 sysinstall.h
--- usr.sbin/sysinstall/sysinstall.h7 Oct 2005 15:56:30 -
1.264.2.1
+++ usr.sbin/sysinstall/sysinstall.h18 Nov 2005 02:09:31 -
@@ -395,6 +395,10 @@
char extras[EXTRAS_FIELD_LEN];
} DevInfo;
+/* systemShutdownNow bitfield flags */
+#define SHUTDOWN_POWEROFF 0x1 /* Power off after shutdown */
+#define SHUTDOWN_NO_RC_CONF0x2 /* Don't attempt to update rc.conf */
+
/*** Externs ***/
extern jmp_buf BailOut;/* Used to get the heck out
Re: Reassigning kernel output to another vty
On 28/11/2005 6:29 PM, Rechistov Grigory wrote: There are at least 8 virtual terminals by default on FreeBSD, but I seldom (to be exact, never) use all of them, mostly the first 3-4. The kernel messages and another ones (such programs as su(1) also print there time to time) are shown on the first vty. So I often get crazy mixture of this stuff, it covers my Midnight Commander's panels till I refresh them. I wonder if there's a method to show kernel messages on, say, 6th console, logs on 7th etc? Such behaviour is well-known feature of many Linux distros and I remember smth similar when installing FreeBSD, when messages of packages are shown on 4th vty. You can easily achieve this by specifying /dev/tty## in the /etc/syslogd.conf file. For instance, change the line: *.err;kern.warning;auth.notice;mail.crit/dev/console to: *.err;kern.warning;auth.notice;mail.crit/dev/ttyv8 Then the message will be directed to the 9th console. Alternatively, you can disable some of the normal login screens in /etc/ttys and then point syslog to use one of the newly freed-up ttys. -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sysinstall install.cfg questions
On 4/11/2005 6:52 AM, Todd wrote: I'm trying to figure out how to use the sysinstall using a install.cfg script to install on multiple machines without floppies, and without needing any interaction other than putting in the CD. I can create the script but don't know where to put it on the modified installation CD, or how to initiate sysinstall during the boot process to use it? Any help will be greatly appreciated! Todd Are you creating your own CDs using a 'make release' (see release(7)) process? If so, I've generally followed an approach similar to the following: 1. Create your install.cfg file in the /usr/src/release/ directory. 2. Create a patch file that will add your install.cfg to a standard /usr/src tree: cd /usr/src diff -u /dev/null src/release/install.cfg ~/local.patch 3. Make the release with the appropriate LOCAL_PATCH parameter: make release \ CHROOTDIR=/some/dir \ BUILDNAME=6.0-MYRELEASE \ CVSROOT=/usr/home/ncvs \ RELEASETAG=RELENG_6_0 \ LOCAL_PATCHES=/path/to/local.path That would build a 6.0 security branch build with your install.cfg in /usr/src/release/ of the chroot. The make release process then takes care of placing the install.cfg in the appropriate location on the CD. If you're attempting to patch an existing CD image, reading /usr/src/release/Makefile suggests you'll need to: - Extract the contents of the ISO - Un-gzip and then mount the decompressed /boot/mfsroot.gz file - Place your install.cfg in the root of the mounted mfsroot fs - Unmount the mfsroot filesystem - Re-gzip the mfsroot file to /boot/mfsroot.gz - Run mkisofs to re-create the CD Hopefully this points you in the right general direction! Cheers Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OFF-TOPIC but ... you will laugh !!
On 3/11/2005 2:31 PM, Aggelos wrote: An Indian discovered that nobody can create a FOLDER anywhere named as con. This is something pretty cool...and unbelievable... At Microsoft the whole Team, including Bill Gates, couldn't answer why this happened! I find it hard no one at Microsoft could answer why that was the case. That harks back to the DOS days, where con used to refer to the the console (ala STDIN). You'd be able to create a text file containing what you typed by doing: copy con file.txt This still works today on Windows XP. And yes, this was completely and utterly offtopic. -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: postfix vs. qmail?
On 29/06/2005 11:13 PM, MikeM wrote: On 6/29/2005 at 8:48 AM [EMAIL PROTECTED] wrote: |For one who wants to host email accounts for multiple domains, which is |better? I've started installing and configuring qmail according to the |tutorial on qmailrocks.org but i'm wondering if i should stop and consider |postfix before pressing on. = I started using qmail but eventually switched to Postfix. I found that qmail required several [conflicting] patches to get the feature level I wanted. I also did not like the need to move my box towards what djb thought a *nix box should be set up. Postfix seems to want to just drop in to a standard environment. But the items that really made the choice easy for me are that the Postfix mailing list is excellent, and that Postfix development is still alive. I host multiple virtual domains with Postfix (and Courier-IMAP for the pop3 amd imap support). I'm another former qmail user who converted to Postfix. I got tired of having to use unsupported patches for qmail to do anything because it didn't fit in with djb's view of how the world should work. Postfix requires a greater time investment in terms of the configuration files, but happily integrates into FreeBSD and is actively developed. (Another echo of support for Courier IMAP as well :-) -Antony ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Looking to build server, best option for reliable FreeBSD supported hardware (SCSI RAID5)?
Hi all, I've been asked to spec out a server designed to pull and store off-site backups from ~60 sites (primary function). The intention is to run FreeBSD on it, although at this point in time we're still deciding whether or not to run -stable (4.x) or -current (5.x) on it; I have a feeling that we may end up having to go with 5.x for driver support. We're looking at probably 4x146gb SCSI drives in RAID5, and I want to make sure we have hardware that's known to work under FreeBSD before we go placing an order. What vendors/equipment are people currently running reliably under FreeBSD (either 4.x or 5.x)? Any recommendations? Thanks! Regards Antony Mawer ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Best Gigabit NIC for FreeBSD?
Hi all, I've recently been setting up a server with a D-Link DGE-500T gigabit ethernet card, that needs to connect to a Novell Netware 4.11 server over IPX. Using the nge driver, it came up on the network fine using TCP/IP, but had issues trying to find the Netware server. A 'tcpdump not ip' showed there were definately IPX traffic/SAP broadcasts being picked up by the card, but it refused to get up and running Changing the card over for a 100mbit one using the vr driver picked the Netware server up without a problem. Has anyone had any experience with gigabit cards running IPX under FreeBSD -- or just in general? We're currently investigating purchasing a different card to try (we were thinking probably Intel - what's supported best under FBSD?). The machine in question is running 4.7-RELEASE-p2. Thanks in advance, Antony PS. Please CC me in any replies, as I'm not subscribed to the list! :) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-questions in the body of the message
