On Wed, Mar 19, 2008 at 06:54:00PM +0100, Casper.Dik at Sun.COM wrote: > > >Then I don't see how SMF/SQLite can protect itself. I mean, the > >contents of /etc/inet/hosts on my laptop had been *completely* replaced > >with some other file's content (I forget which). I wonder if the fact > >that the system came up without forcing single-user mode (to manually > >fsck /) had anything to do with that. > > But of course it can! It's just not easy.
Well, that UFS problem seemed so random... (or perhaps DHCP was updating my hosts file?) > There are system calls which allow you to ask UFS for a guarantee; you > will need to go from one such state to the next with judicious use > of the appropriate system calls. But that is not easy. ZFS is much > better in that respect because it is transactional itself. > > Only once fsync() has returned the transaction is complete and you must > guard yourself against all intermediate states. IIRC SQLite first writes to the journal and fsyncs that, then it writes to the DB and then fsyncs that, finally it removes the jorunal. > >Again, the config file wouldn't go away; the purpose of this proposal is > >to make it easier to setup new instances that differ very little from > >the default instance, not to completely change how sshd is configured. > > Is that really that simple? A lot of sshd's config is considered rooted > in /etc/ssh. What bits would you replace and what bits would be pertinent > to the ssh clients (of which there would be only one class)? This would apply only to sshd, not to ssh. The commonly overridden parameter would be Port, and maybe HostKeys. Nico --
