Re: rc.d/jail issues
On Thu, 27 Jan 2011, Paul Schenkeveld wrote: like to start A before B but shutdown B before A. Would it make sense to reverse the order in which jails are stopped during shutdown by reversing the nales in $jail_list? Yikes, it does indeed make sense, that's why I already do it in the ezjail utility, besides having jail dependencies worked out by rcorder... Now, if /etc/rc.d/jail starts to reverse the list ezjail reverses before, I'm in trouble. Maybe it's time to think about moving some more jail abstraction - including jail dependencies - to the base system. erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: rc.d/jail issues
On Thu, 27 Jan 2011, Jamie Gritton wrote: That's where it's headed. I've been slow on progress lately, but I'm working on a jail(8) that takes a config file instead of rc shell variables, and takes care of dependency issues among other things. Looks like I completely missed the discussion that went on in June this year. If I can be of any assistance working on a new jail(8), I'd be too happy to know how I can help. Is the progress visible somewhere? erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Detecting listening servers in multi-ip jails
Hello,
until jails could be bound to several ip addresses, my convenience
feature in ezjail to check for and warn about listening services in the
host system and other jails worked simply by asking:
listeners_ip=`sockstat -4 -l | grep "${ip}:[[:digit:]]"`
listeners_all=`sockstat -4 -l | grep "*:[[:digit:]]"`
Now where ip adresses are not rewritten on listen() calls anymore,
services in jails can bind to 0.0.0.0 as well and will match the latter,
although they don't really cause the trouble I want to warn users about
(unless, of course the jail really is bound to the same ip address and
the service then binds to 0.0.0.0).
Now I can, using "nc -z", test if the service really listens. That
allows me to filter and only report those services that actually
respond. However, this is far from clean.
Are there other ways to relibly test for listening services on any port
for a given ip address?
Thanks in advance,
erdgeist
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
pop filters from kqueue
Dear fellow FreeBSD hackers, while writing a daemon that uses a kqueue to keep track of forked processes and pipes to userland client code etc, I noticed a lack of features to implement a proper shutdown without holding data redundantly. When my daemon quits, I can not ask the kqueue for my installed filters and get back the udata I passed to the kqueue. This is unfortunate, because I like the idea of having only one owner per memory allocation. The most obvious use would be a per-fd-state held in a memory block. When passing it to kevent() via the udata entry, I would make this filter the owner of my allocation. However, when gracefully shutting down, my daemon has no way of retrieving all the values passed to the filters. For most cases that may be okay: memory allocations will just be thrown away on exit(), anyway. But once I need to clean up external state, like sending signals to processes I installed an EVFILT_PROC for etc, I need to keep a redundant list of pids and the associated udata. This violates the rule of strict ownership and introduces room for inconsistencies. Is there a specific reason I have overlooked that would forbid popping untriggered filters from my kqueue? Or is there even a way to do so that I have missed? Regards, erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: pop filters from kqueue
On 05.03.13 17:53, Alfred Perlstein wrote: Alfred, > I'm not sure if kqueue support this, however adding such a facility > might be OK. thanks for your reply. What would be the correct place to suggest such a change? > The only pain here is that it requires managing a doubly linked list and > additional pointer dereferences. Which seems extra absurd in the light of a performant implementation already handling all this - within the kqueue. And it still does not solve my problem that for every operation on my allocation I need to update pointers both in the kqueue and in my linked list. Regards, erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Managing userland data pointers in kqueue/kevent
On 13.05.13 11:19, Eugen-Andrei Gavriloaie wrote: > Regardless, it has all the ingredients for memory leaks and/or, the > worst one, use of corpse pointers which are bound to crash the app. I I earlier pointed out other things that prevent me from using kqueue as a proper storage for user land pointers: http://lists.freebsd.org/pipermail/freebsd-hackers/2013-March/042181.html To sum it up, once I pass a pointer via udata to the kqueue system, kqueue becomes the owner and the expected behaviour is (a) never silently swallow the pointer (b) provide an interface to retrieve the pointer anytime Besides the way you pointed out to violate (a), there is another way, re-adding an existing event. So I propose a flag EV_EXCL that will fail adding an existing event with EEXIST in data. As an alternative or in addition to that, re-adding an existing event without the EV_EXCL flag will cause the old event to be returned with the EV_DROPPED mechanism proposed. This can also be used to fulfill property (b). kqueue is an efficient store for the per-event-data. In an event base application, I usually allocate resources per new session, pass the metadata via udata to kevent and will see the udata pointer whenever the event triggers. But in order to clean up resources due to external events (like program termination), I have no way to ask my kqueue for the kevents (and thus the udata) I stored in them ... without knowing about them in the first place. For the program termination case, it would be enough to extend EV_DELETE with a flag to drop all filters and catch them by checking for the EV_DROPPED flag. This means that EV_DELETE could return a list of filters and can be called several times until no events are returned. Of course this can be extended to specifically drop events that match a certain filter, flag or fflag value, but for now you can also use different kqueues. Regards, erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 26.05.13 01:07, Nathan Whitehorn wrote: > I'm not aware of any movement there (on either side of the table). I'd > personally be very suspicious of an all-sh(1) future -- by far the > cleanest parts of bsdinstall are in C -- and this is especially true for > interacting with geom. That said, since I've lost nearly all of my free > time and ability to work on bsdinstall, I won't get in the way of anyone > else working on things As discussed at BSDCan, I'd be willing to participate in the development and at least implement setting up zpools/zfs and geli/gbde providers. I have done similar things in sh in my ezjail tools and think I can glue the rest together. Scanning through the pc-sysinstall code, I find nothing too fancy there regarding either interaction with zfs nor geom tools. I do not think it is necessary as a back end just for these features. Nathan, is there any design rationale available for the scripts, e.g. on why you chose sh versus C and were you provided with some kind of wish list/requirements in the first place? Any particular mail thread to scan through beforehand? Regards, erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 26.05.13 04:51, Super Bisquit wrote: > Please don't turn this into an architecture dependent mess. PCBSD is > i386 & AMD64 only. Read my email thoroughly and notice that I never seriously considered using pc-sysinstall after looking into it. Don't worry. erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: FreeBSD installers and future direction
On 26.05.13 05:42, Teske, Devin wrote: > I chose 100% sh for bsdconfig because of a few good reasons… First, the partedit tool makes heavy use of libgeom and the structs returned from that lib, so I've rather wondered why for some parts C was preferred, and not the other way around. Still, thanks for pointing all that out, but I rather wanted to look at the installer from another angle, as it is supposed to provide everyone from FreeBSD novices to experts with a comfortable way to do things the right way and yet be flexible enough to avoid abandoning the tool once the requirements differ. So I wonder if there has ever been a best practices document on how to "properly" set up zpools, when to advice the user against using zfs at all, whether it makes sense to use geli on the boot device, when it is better to have multiple zpools and only encrypt the data pool(s). Maybe the installer should be advocating concepts like manageBE, pre-setting noexec-flags on /var, setting some default quotas. The second part, of course, is to find visual concepts on how the user is guided through the default and expert bsdinstall/bsdconfig screens to cover the most common scenarios and still offer enough options. All this doesn't need a developer but a bunch of veteran FreeBSD admins, a wiki and a lot of bike sheds to paint. If there's no such document yet, I propose editing one in the wiki. erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Fix MNAMELEN or reimplement struct statfs
The arbitrary value
#define MNAMELEN88 /* size of on/from name bufs */
struct statfs {
[...]
charf_mntfromname[MNAMELEN];/* mounted filesystem */
charf_mntonname[MNAMELEN]; /* directory on which mounted */
};
currently bites us when trying to use poudriere with errors like
'mount: tmpfs: File name too long'
/poudriere/data/build/91_RELEASE_amd64-REALLY-REALLY-LONG-JAILNAME/ref/wrkdirs
The topic has been discussed several times since 2004 and has been
postponed each time, the last time when it hit zfs users:
http://lists.freebsd.org/pipermail/freebsd-fs/2010-March/007974.html
So I'd like to point to the calendar, it's 2013 already and there's
still a static arbitrary (and way too low) limit in one of the core
areas of the vfs code.
So I'd like to bump the issue and propose either making f_mntfromname a
dynamic allocation or just increase MNAMELEN, using 10.0 as water shed.
Regards,
erdgeist
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: disassembler
On 27.08.10 04:17, Aryeh Friedman wrote: > Is there a disassembler in the base system if not what is a good > option from ports? Try objdump -d, erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Jails, loopback interfaces and sendmail
Dear fellow hackers, since jail can be bound on multiple IP addresses I tend to clone multiple loopback interfaces and add one loopback address to each jail cloned_interfaces="lo1 lo2 lo3" ifconfig_lo1_alias0="inet 127.0.0.2 netmask 0x" ifconfig_lo2_alias0="inet 127.0.0.3 netmask 0x" ifconfig_lo3_alias0="inet 127.0.0.4 netmask 0x" .. no this is not yet optimal, since I can not run several jails on a single external IP anymore, but at least local daemons are not visible to the outside world, anymore. However, grep -R 127.0.0.1 /etc reveals, that sendmail in many places assumes localhost to be on 127.0.0.1 instead of looking it up in /etc/hosts or using 127.0.0.0/8 to identify a local connection. I worry that more programmers made those assumptions, possibly breaking more tools. My question is: Who's the right guy to beg to fix sendmail or alternatively would it be smart to allow each jail to have its own concept of 127.0.0.1 on a dummy interface mapped to all jails, that itself doesn't count as a bound IP address (thus allowing the jail to bind to an already bound ip address) and is not routed between jails? Any ideas? erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
RE: How to slow down SATA to 1.5 GBit/s ?
Sent from my HTC ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Using pkg_add fetch only
Good evening, I'm writing on the ezjail project and want to be able to use the easy interface of pkg_add to fetch packages recursively. This is _fetch_, not install them, since installation is expected to happen at a later stage when starting up lots of jails each being identical. Clearly pkg_add does not provide this option. Even if it would, it would declare some dependencies fulfilled since packages are installed in the hostsystem already. Anyone having an idea here, besides rewriting pkg_add? Regards erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using pkg_add fetch only
On Fri, 6 Jan 2006, Matt Emmerton wrote: What about pkg_fetch -R? This command is not in the base system. Since there is some logic in pkg_add for resolving dependencies and fetching packages I hoped, there might be some easy way not involving additional dependencies. But thanks for the hint, anyway. erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using pkg_add fetch only
On Fri, 6 Jan 2006, Ceri Davies wrote: The package cluster uses chroot() for this. Sure, but some post install scripts better run inside the running jail, those script will do stuff like creating users and installing files with user ids that are not even there in the host system. Thanks anyway. erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using pkg_add fetch only
On Fri, 6 Jan 2006, John Baldwin wrote: I use a shell script that downloads a package with fetch, extracts +CONTENTS to a temporary directory and parses it for dependencies, then downloads any missing dependencies and adds them. This sounds like the most reasonable solution. I can't assume the user to run a current version of pkg_add and grepping for dependencies is not that hard.. only pity is that I would be duplicating code that is already there in the base system. Thanks erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using pkg_add fetch only
On Fri, 6 Jan 2006, Ceri Davies wrote: I don't see your point. I thought you just wanted to download the packages and dependencies. Yes. pkg_add on the other hand leaves me with loads of _installed_ packages but without the package tars from the server. erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Using pkg_add fetch only
On Sat, 7 Jan 2006, Ceri Davies wrote: Two stage process. In chroot(), pkg_add -r portupgrade, then pkg_fetch -R the stuff you want. Once you're done you can just blow away the chroot environment and all the installed stuff. So I win nothing besides having to set up a complicated three-stage chain. chroot() by itself will not be enough as long as the portupgrade tools are not compiled static. Sure, it'll install a bunch of other crap like ruby, but it's a lot easier than hacking up your own tool. From the ezjail Homepage: "Since ezjail is written entirely in sh, there is no need to install other script languages into the Host-system" So: No way. But your help has pointed me into the right direction. erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: tuning to run large (1000+) numbers of null_mounts
On Wed, 18 Jan 2006, Devon H. O'Dell wrote: This has been removed from the manpage because it's no longer accurate. I believe I recall seeing another thread with someone asking whether it still applied and the answer was, ``No.'' On a test installation I am running > 100 Jails with around 200 nullfs read only mount points and had had no problems with nullfs for 7:59pm up 54 days, 22:46, 5 users, load averages: 0,25 0,37 0,38 Regards erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: dump(8) performance
On Wed, 31 May 2006, Eugene M. Kim wrote: read throughput was exactly twice as high as the tape write throughput, throughout the entire dump phases 4 and 5, i.e. dumping actual inodes. Disappointing, because the tape drive utilization (%busy) was lingering around 35%-50% for most of the time; I didn't expect the disk would be the bottleneck. :p I had a similar experience when dumping my mailserver. In addition I noticed that for a user with >30 files (spam mails) in one directory it caused dump to sit back and think for half an hour before proceeding. I always resolved to look into the code to find something O(x^n) but didn't have the real urge. DID someone here look into that? Regards erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Strange keyboard (viral?) behaviour
On Mon, 12 Jun 2006, Philip Lykke Carlsen wrote: Around yesterday my computer suddenly stared acting really strange :s It started typing on its own. and it seemed to be typing things that I had been typing over GAIM a week or so ago, complete with typo's beeing corrected the same way that i had made them originally. Try http://en.wikipedia.org/wiki/Keylogger Regards, erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Rebooting jails
Hello, I'm currently looking for a standardized way to 'reboot' jails from within. 'shutdown' is a simple one, just issue 'kill -TERM -1' and you're done. Now, rebooting generally involves starting up the jail afterwards. One way that works from a shell started via jexec would be to 'kill -TERM -1' all processes and execve into whatever is supposed to be the kickoff command, e.g. /bin/sh /etc/rc. However, doing this from a shell that has been run from sshd results in killing the sshd and thus the shell trying to restart the jail. Another way would be to have a daemon waiting in the host system that is checking jids in /var/run/jail_*.id say all 5 Minutes and if pgrep returns anything than 0, the jail is being restarted (you may combine that with some conditions, say having a file '/.rebootme' under jail's root directory). This approach is more a watchdog than a reboot mechanism, you would need to do unintuitive stuff like adding a line to crontab (where it would even run if no jails are active, which sucks). One could use an 'at +5m $prefix/bin/watchdog' in the script that starts the jail in the first place which calls itself the same way. All this is annoying to track, a watchdog script sleeping in the background would more easily be visible in ps. And, waiting for the host system to finally rerun to jail may cost many boring admin-5min-periods. Maybe someone can help me out with a cool idea. Regards erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A handy utility (at least for me)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rick C. Petty wrote: > On Sat, Aug 26, 2006 at 07:19:06PM -0300, Mario Lobo wrote: >> My /usr/ports directory was occuping 24 gigs, of which 20 was just from the >> 'work' directories ! >> >> Removing them one by one was a pain so I wrote this little utility to wipe >> them off. > > I find that the following command works just fine for me: > > find /usr/ports -type d -name work -prune -print -delete And EVEN cooler is having a WRKDIRPREFIX= /var/ports in your /etc/make.conf, that way an "rm -rf /var/ports/*" cleans without unnecessary directory recursion. Regards erdgeist -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD4DBQFE8NM1ImmQdUyYEgkRAh4OAJ4m2S/EckiXj3N95NDba5TjW+z54gCY8CNp 5xvH4mLR9Kttl9KdB6NGBA== =F5cq -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: A handy utility (at least for me)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Roman Kurakin wrote: > A bit rude, but also works > > cd /usr/ports && make clean This one takes ages, every port is being cleaned which in turn cleans every dependency, so low level ports will be "make clean"ed thousand times. Better would be for port in /usr/ports/*/*/; do cd $port; make NOCLEANDEPENDS=YES clean; done Regards erdgeist -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE8NU7ImmQdUyYEgkRAqHTAJ9Q4XFOgg144pkIZ6mPvE5OCNx0NgCgkafL 4aun8IXwJaJSRx1eRVO1dMY= =f5Mj -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
jails, cron and sendmail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello, I have the following problem: since I need and do not like any kind of smtp activity in my jails (there's no 127.0.0.1 in a jail, all services listen to the jails external interface), I put those lines into my /etc/rc.conf: sendmail_enable="NO" sendmail_outbound_enable="NO" sendmail_submit_enable="NO" this works fine: nothing listening on the jails interface... except that cron tries to deliver its status mails and fails. While failing, sendmail seems to hog cpu and finally floods /var/spool/clientmqueue and /var/log/maillog. My quick fix now is to replace /usr/libexec/sendmail/sendmail with /usr/bin/true in /etc/mail/mailer.conf, however: it seems problematic that cron insists on a mail sub system, when all it should do is execute stuff periodically. There should be an option to let it only log to a file. For my jails this would make sense, too: I never read root's mails locally, anyway. Am I missing the obvious solution here? erdgeist -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE8OOPImmQdUyYEgkRAlg8AJ94cvRnJO8y04wZdYdzaX1YM4SorACffJtE DN2NRiU437SGchnsOrh5hQs= =t0dd -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jails, cron and sendmail
On Sat, 26 Aug 2006, Mike Meyer wrote: Except some of the things run from cron want to send mail all on their own, so fixing cron won't solve your problem. Why are you running cron inside the jails at all? Are you letting your users run it? If not, can you disable it, and instead run scripts from your real crontab that do the appropriate thigns in each jail? It's not me, it's the OS running cron to do its periodic checks, per default. But Daniel Gerzo already pointed out, how to solve that. Still: FreeBSD's /etc/ assumes and provides a working mail subsystem in its default configuration. That exposes sendmail to the publicly visible IP address. Shutting the mail sub system off causes trouble. I hope, that describes my motivation to bring up the topic. erdgeist ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jails, cron and sendmail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Gregory Shapiro wrote: > Unfortunately, in jails, localhost gets remapped to the jail IP > address and therefore, he is correct, it is accepting connections > from the outside world. This is one thing that I would love to > see fixed in jails. There was a multiple IPs in jails patch for 5.4, which would fix that issue, but until loopback interfaces exist in jails, I'd love to see an easy way to turn off smtp. Regards, erdgeist -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE8bRjImmQdUyYEgkRAmH1AJ9magSHG86M5J2u1SJw+L+jx+hE5QCeKsvG bfjWWGE0Ipks6EhG9jMTtkM= =JRre -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: jails, cron and sendmail
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Mike Meyer wrote: > That's just a default. You can can change it by adding > cron_enable="NO" to /etc/rc.conf in each jail. So maybe the question > should be "Why haven't your turned off cron in the jails?" Because the system uses cron to start its periodic scripts. The periodic scripts are cool and useful in jails, especially the security scripts. Thus I wont turn off cron. >> Daniel Gerzo already pointed out, how to solve that. > > By checking periodic.conf? That doesn't prevent cron from sending > mail; that just turns off the periodic scripts that cron launches, > some of which also send mail. But it prevents a vanilla system to try to connect to localhost:25 once a day. Only those periodic scripts send mails per default. > In order: right, wrong and right. I'm afraid, you're wrong. > The default configuration doesn't expose sendmail to the publicly > visible IP addres. The daemon it runs only listens for connections to > the localhost address. Which is rewritten to the jails (externally visible) address on a connect() > If your concern is that shutting off a subsystem can break things - > I'd say that's a *good* thing. One of the things that make Unix > powerful is that it assumes the user knows what they are doing. This is... a strange opinion... If the default exposes an unwanted service to the world, then turning it off should not require indepth knowledge in how to prevent other things in the system to break. The service should not even be there in the first place. > Given the choice between a system that does exactly what I tell it > to, and one that second guesses me, makes changes behind my back, and > makes setting things up the way I want a PITA, I know which one I > want. I would chose and recommend the system that provides sane and secure defaults without requiring me to understand all of the OSs sub systems. Detecting that /etc/ is inside a jail environment and adjusting your sendmail and periodic settings would be a nice thing to have. Regards erdgeist -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFE8be3ImmQdUyYEgkRAhogAJ9PDDu5SkZOp15OmzAt/Tfx8yW2zwCgg5Qo sjq1PJ/f3u3gIUiPuX8sbm8= =ouev -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Phantom Jails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Rumors went around and tales were told about jails magically booing around in prison list, even after they deceased. Most people consider this a rather aesthetical issue, however if you run your jails from directories that need to be unmounted (e.g. from md-images, on external drives, from gbde or geli images) those phantom jails become rather annoying, since you cannot umount their roots. Investigations have shown, that 1) sockets hold a lock on (increase reference counter in) the ucred structure of the calling process 2) This ucred structure in turn keeps a lock on (increases reference counter in) the prison struct representing the jail this process belongs to 3) The prison struct in turn keeps a handle to jails root directory. If a process holding a tcp connection is killed, the connection is being inherited by the kernel. It waits there for tcp tear down or tcp time out to occur. Only then socket's lock on ucred is released, which releases ucreds lock on prison struct (thus terminating phantom jails) which may, if it is the last ucred referencing the prison, release the prison and its handle to the root directory (solving my un-umount-able images). There were kinds of phantom jails being sighted, that did not vanish after tcp timeout, that might be deadlocked by open files or mmaped regions. However the above case happens regularly with my mail server jail that holds hundreds of imap-connections, one disconnected dsl-user can prevent tcp tear down to happen successfully thus forcing me to force umount the mail server. My suggestion would be (I will provide a patch, if discussion produces no major disagreement) to release ucred structs held by sockets as soon as the process dies. They are being used for accounting purposes only, anyway. The same may apply to the other types of phantom jails, as well. I could not create those deliberately and therefore can not exactly spot the proper location to fix. Comments? erdgeist P.S.: if you want to reproduce a phantom jail try the following: 1) create and start a jail 2) Start a ssh/web/whatever server within the jail 3) Connect to that server from the host system. 4) Keep this connection open while you kill the jail 5) Do a 'jls' and compare its output to "ps axuu | grep J" 6) Kill the process that connected to the service. 7) Do a 'jls' again. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFXSp5ImmQdUyYEgkRAtOAAJ4iSzyu2LOf+RBNArvYAk1Tv8cssACfRxJa 12OGEwWugcIDhlGGTHJrz0o= =gXK8 -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Phantom Jails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Bjoern A. Zeeb wrote: > while this works you can also reproduce it if you log out of the jail > wait for the sockets to go away entirely and then stop the jail > because what keeps the jail up is not a socket but is related to devfs > and ?tys. > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/89528 So you're implying, that releasing the ucreds, that in this case obviously prevent prisons from disappearing, won't work due to stuff that "is releated to devfs and ttys"? Or was that a kind request to have a look into potential ucred leaks in tty and devfs code, as well? :) What unwanted effects could an early release of ucred structures cause? Maybe it was the wrong list to put that question on, after all, which would be appropriate? Regards erdgeist -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3 (Darwin) iD8DBQFFXgztImmQdUyYEgkRArfGAJ0VzR2klSbK/39KSfIGiumrp9ET4ACdHEW5 Hg1YMGukSTzh44TxRHFkGpE= =60Hb -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
