Re: new rc system
On Thursday, September 11, 2003, at 04:36 AM, Peter Jeremy wrote: On Wed, Sep 10, 2003 at 05:00:49PM -0700, Doug Barton wrote: [re-ordering rc.d scripts] This is a known shortcoming in the new rc system. Luke Mewburn commented on it in a talk recently but does not yet have a satisfactory solution. Can you describe in more detail what you mean by "this is a known shortcoming?" The files in /etc/rc.d/ include dependency information in the form of 'BEFORE' and 'REQUIRE' entries. The default entries are appropriate for "normal" configurations but may require changes in some cases (eg Philipp's situation). The new rc system currently has no mechanism for over-riding these defaults other then by editing the individual rc files. These changes need to be re-merged if the rc files are updated. Luke is currently looking at options to allow administrators to alter the dependency order without requiring the rc files to be edited. Two possibilities are: 1) An option to rcorder that allows dependency information to be included on the command line. 2) Add a hack to rcorder so that given a file /etc/rc.d/foo, it will check for dependency information in /etc/rc.cnf/foo. My initial inclination was to write a couple of pages of ideas, for improving the rc subsystem. On second thought, I think it better not to include them until I know the appropriate recipients and/or venue. I'm not currently a contributor, am new to the freebsd-* lists, and do not yet know the people and their responsibilities. I am responding, however, because I have a number of ideas on how to improve the rc subsystem, and am willing to contribute both time and code if a new design grabs me. Except for contributing minor patches to gnutar, amanda, procmail, I'm new to opensource development. I do, however, have 20 years experience with Unix development and administration, and 4 years experience with a mix of FreeBSD 4.x and 5.x, so I should not take long to ramp up. So, whoever is responsible for this stuff, if you have room for a new person on your team, please let me know how I can get involved. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw - default to accept + bootp = confusion.
On Thursday, August 7, 2003, at 02:23 AM, Juli Mallett wrote: * James Quick <[EMAIL PROTECTED]> [ Date: 2003-08-07 ] [ w.r.t. Re: ipfw - default to accept + bootp = confusion. ] On Thursday, August 7, 2003, at 12:22 AM, Juli Mallett wrote: Does someone have any idea what approach to take for the following scenario? I'm leaning towards a compile time failure, or an informative panic at the beginning of bootp... You have IPFIREWALL, but not the default to accept option, and you have BOOTP. The BOOTP stuff will fail in sosend with EACCESS (informatively printed as "13"), because of IPFW, and this may be slightly non-obvious to people who haven't dealt with early ipfw interference before. If not compile time failure / panic, I'd say probably we want some way to notify a user in general of ipfw stopping pre-init operation, but I don't want to add the concept of runlevels, and don't know if there's anything there currently to do detection of if we've hit that point yet. If the default rule controlled by IPFIREWALL_DEFAULT_TO_ACCEPT, default_rule.cmd[0].opcode, were made accessible via a sysctl. then bootp could check it and produce an informative message. Or, if possible try to insert a rule into the kernel restrictive enough to be safe. On the one hand it's a firewall, and you don't want to be It's entirely easy/possible to add such, but I'd rather not have a dumb sysadmin blame me for their firewall supposedly getting punctured. If you have BOOTP on a box, defaulting to DENY is insane. Does that mean I want to just *change* things at runtime? No. I'd rather prevent any foot-shooting of any form. Given the current implementation, the situation is "insane". However, In a wider context, it might be worth looking at the configuration decisions in terms of allowable site policy, rather than dismissing the combination as worthless. Regarding foot-shooting, I agree that bypassing the deny rule to finish booting needs to be analyzed carefully and made explicit to the user, through a combination of documentation and/or user intervention. and/or documentation. I believe however, that the point is largely moot. A foot is already bloody at this point, isn't it? Given the current behavior, the critical path is the conjunction of three or four events. Only one of which is compilation. Complaining or halting during compilation, or requiring additional action to get a quiet compile seem ill-advised. They add complexity to the common path in order to flag a possible error which could only occur in the context of several other independent (and uncommon) events. To reach this point the kernel has to be: 1. Installed as a resource on a bootpd or tftpd server. 2. Loaded by a system configured to boot it, because: a. They are diskless b. They suffered a loader failure from local disk and are attempting a more graceful failure by booting from the network. The "insanity" of the configuration, is thus dependent both, on a number of configuration choices outside of the kernel, and the current implementation, which has no choice but to fail. I think this is best viewed as a matter of defining allowable policy. Making a decision about how to handle this situation, has direct impact on the choices available to the end-user in defining site-wide architecture. In the default configuration, sites have the choice of either using diskless workstations, or configuring hosts with local disk to perform a network boot after an initial failure. Also, in the default configuration, sites have the choice of using ip_fw as a mechanism for reporting on, and/or enforcing, their network policy. Finally, it seems good policy for any large site to reduce complexity by using the same kernel for a network boot, as is normally used from disk. Thus providing the option to remotely boot a kernel which now makes sense only locally, is not as insane as it appears initially. Each of these site policies in isolation make eminent sense. The questions for you become: "Do want to provide additional support for sites who wish to implement net booting as a response to end-user hardware failure, and whose security policy defines the use of default deny rules for it's workstations?". If the answer is no, then fine. Report as much detail as you can before halting. If the answer is yes, then, documenting that the "client host will accept the following packets, during a network boot, until later configuration overrides it.", does not seem out of line. In either case, it makes the allowable policy explicit. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
What parts of disk geometry are relevant?
I'm setting up 5.1 with a couple of new drives. Sysinstall, and for
that matter,
any combination of command line tools, all seem have different ideas
about
geometry. Sysinstall would use any of the numbers I threw at it, and
even after using sysinstalls values, fdisk and bsdlabel find reasons to
gripe.
Configuration data:
The geometry from the manufacturers docs, which is reported several
times at boot, is: 152627MB [310101/16/63].
The geometry mandated by sysinstall is: 19475/255/63
(The drive physically has 2 platters and 4 heads - but at least 16
is a multiple of that)
Both sysinstall-help and most of my web research says that the
way to be sure about what to use is to boot to dos or windows and
see what it says. That is hardly convenient as my only use of Intel
based systems has been confined to {NeXT,Open}Step and now
FreeBSD. What does DOS know that FreeBSD doesn't?
I'm migrating from a 2+ year old 5.0 installation, which is in
production
use, so I don't have the luxury of just playing with the parameters to
see what boots and what doesn't.
As far as compatilbilty goes, I need 5.x BootEasy, the loader, and the
kernel to be happy about all the slices+partitions on the drive.
If there is any difference, Compatibility with 4.x as well would be
nice but is not required.
I'll ask two questions first, since yes answers will relegate the others
to matters of idle curiosity.
1. If newfs succeeds for a ufs2 partitions extending beyond 120GB,
does that mean the configuration is OK?
2. Is sysinstall's cryptic refusal to use the reported values, (and
astoundingly
poor choice of alternate values), solely to ensure that Wintel OSes
sharing
the drive don't get confused?
(c'mon 255 heads? And don;t get me started about a cylinder size
whose factors are all prime!!)
If the answer to either of those is no, I would appreciate further
clarification.
The rest of my confusion surrounds related issues of geometry, and
whether or not they are important, or irrelevant.
The original design of ffs/ufs mkfs was heavily dependent on geometry
for performance and reliability. These are memories from v7, but
I seem to recall that rpm, skew factors and interleave were important,
and that incorrect vs. correct values had significant impact on both
performance and reliability. bsdlabel -A reports 3600 for rpm (a very
old default) interleave is 1, and the rest are 0. Are these just legacy
structures on disk, or is anyone paying attention to them?
Fdisk reports cylinder numbers which obviously depend on the geometry
used when the partition (slice) was written. It always complains that
the in-core disk label will not work beyond cylinder 1. Is this more
pandering to DOS or can I ignore it?
Bsdlabel complains about c partitions not covering the whole unit.
I checked and found that sizes of all defined partitions sum to c, and
that the size of c equals the size of the slice reported by fdisk.
I checked the code, and it seems to be saying that by 'c' partition
in a slice doesn't cover the whole drive. In that case, the warning
just seems out of place. Is that what's going on?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Questions about stability of snapshots and vinum in 5.1
My goal is to have a box, with 2 drives, each of which is identically configured. Slice 1, and Slice 2, will be smallish FreeBSD partitions 4-8 GB each. 1 will be treated as a production environment. The other will be used for building and testing new environments. The bulk of the space will be used for data. Each pair of production and test slices will be periodically mirrored to it's twin to provide a measure of fault tolerance. The box currently has one of the two new large drives installed, and 3 smaller aging (and ailing) drives. I was hoping to use vinum for all the rest, as it would give me far more flexibility. Based on recent posts it sounds like I should wait on that, and will leave enough unconfigured space at the top so that I can migrate from manually created partitions to vinum once I feel that geom+vinum have stabilized a bit. I am seeking feedback on the status of vinum, and whether the following plan makes sense as an upgrade plan for a host with a light load but whose downtime windows are short. I am curious if my planned use of snapshots is risky in 5.1, I have used them in under a much older 5.0 version with no problems, but a lot has changed. I have not migrated my data onto the first of these drive since I need to configure one, migrate from 2 old drives, then put in the second new drive before continuing. I also need to do as much of this work as possible without interruption. My plan is, to build out the first set of partitions, then create a queue of jobs for each disk controller: 1. create a snapshot on the destination drive. 2. use dump+restore or tar at a decent nice value, to copy from source to the new dest. 3. Then when I can shutdown production, and all the old data has completed a full (though aged) copy, get rid of the old mirrors. Use rsync to copy the changes to the destination. 4. Create snapshots on the new system volumes, boot into the new environment for testing. 5. If that goes well, swap out one of the old drives for the second new one, build out the OS copies, and copies of critical user data. 6. I can then get rid of, or fool around with the old disks at my leisure. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ipfw - default to accept + bootp = confusion.
On Thursday, August 7, 2003, at 12:22 AM, Juli Mallett wrote: Does someone have any idea what approach to take for the following scenario? I'm leaning towards a compile time failure, or an informative panic at the beginning of bootp... You have IPFIREWALL, but not the default to accept option, and you have BOOTP. The BOOTP stuff will fail in sosend with EACCESS (informatively printed as "13"), because of IPFW, and this may be slightly non-obvious to people who haven't dealt with early ipfw interference before. If not compile time failure / panic, I'd say probably we want some way to notify a user in general of ipfw stopping pre-init operation, but I don't want to add the concept of runlevels, and don't know if there's anything there currently to do detection of if we've hit that point yet. If the default rule controlled by IPFIREWALL_DEFAULT_TO_ACCEPT, default_rule.cmd[0].opcode, were made accessible via a sysctl. then bootp could check it and produce an informative message. Or, if possible try to insert a rule into the kernel restrictive enough to be safe. On the one hand it's a firewall, and you don't want to be making assumptions about trust on behalf of the user. On the other hand, we just accepted a kernel from someone, and now want to get some data for a root partition, so if we cannot trust the host we're booting from, what's the point? Given the above, would it be possible, to embed a small function taking just a pair of addresses and masks, and use that to add a rule so that this process could continue? After using sysctl to verify the predicament, you could then try installing one (or a few) rules to trust the machines that are booting us. Trust the server running bootpd, trust the dchp and nfs server, or just trust the network+submask in a single rule. the following is just a rough guess from looking at ip_fw.c. I don't know how far off it is to being valid. s = socket(AF_INET, SOCK_RAW, IPPROTO_RAW); if (s < 0) err(EX_UNAVAILABLE, "socket"); memset(&rule, 0, sizeof rule); rule.fw_flg |= IP_FW_F_ACCEPT; rule.fw_prot = IPPROTO_IP; rule.fw_src = /* the bootp servers address rule.fw_smsk = ~0; /* Does all 1s mean just from that host? */ rule.fw_dst = /* Is our addr known yet? */ rule.fw_dmsk = ??; rule.fw_flg |= (IP_FW_F_OUT|IP_FW_F_IN); /* you could do both directions */ i = sizeof(rule); if (getsockopt(s, IPPROTO_IP, IP_FW_ADD, &rule, &i) == -1) err(EX_UNAVAILABLE, "getsockopt(%s)", "IP_FW_ADD"); Is any of this reasonable or I am just being naive? (I'm new here.) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
