Re: FreeBSD needs Git to ensure repo integrity [was: 2012 incident]
On Sat, 17 Nov 2012 21:11:43 +0100, Ivan Klymenko fi...@ukr.net wrote: В Sat, 17 Nov 2012 15:00:06 -0500 grarpamp grarp...@gmail.com пишет: http://www.freebsd.org/news/2012-compromise.html http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key This is not about this incident, but about why major opensource projects need to be using a repository that has traceable, verifiable, built-in cryptographic authentication. LOL And how will this help Linux? http://lwn.net/Articles/457142/ In the first comment on the article you link to, you find this: http://www.linux.com/news/featured-blogs/171-jonathan-corbet/491001-the-cracking-of-kernelorg where the OPs view is susbstantiated. ___ freebsd-questi...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 21.06.2012, 12:22 Uhr, schrieb Wojciech Puchar woj...@wojtek.tensor.gdynia.pl: Lets make a summary. What functionality would be good to have in FreeBSD that doesn't exist: 1) runlevels with arbitrary names. runlevel change would start and stop right services. 2) exploit startup parallelism. What we do not want to change: - file structure which is simple. one file in rc.d/ per service and one global config file (rc.conf) - anything else that would make things more complicated. As for 1) i propose in rc.conf an option to put NO, YES (or ALL) or runlevel list for each service or runlevel exclusion list for service. examples: service1_enable=YES service2_enable=NO service3_enable=foolevel maintenance service4_enable=YES -foolevel (or ALL -funkyrunlevel) name of default runlevel may be full or multiuser service 1 will always work, service 2 never, service 3 only at runlevels foolevel and maintenance, service4 with any runlevel except foolevel. still single rc.conf, not much bigger in practice. 2) no change in rc.d/* scripts and rc.conf, but change in scripts. If everyone agree i think i may write this new scripts. Nicely thought. Count me in for testing. Do you think it would be possible to have something along the lines of ifconfig_em0=inet ... ( default (or unknown) runlevel ) ifconfig_em0_foolevel=inet ... ( foolevel runlevel ) ifconfig_em0_maintenance=inet ... ( maintanence runlevel ) too ? Michael ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 21.06.2012, 12:56 Uhr, schrieb Wojciech Puchar woj...@wojtek.tensor.gdynia.pl: ifconfig_em0=inet ... ( default (or unknown) runlevel ) ifconfig_em0_foolevel=inet ... ( foolevel runlevel ) ifconfig_em0_maintenance=inet ... ( maintanence runlevel ) too ? well - possible BUT... but well. this will not require only changing launcher script for rc.d/* things but scripts itself. and extra flag so launcher at runlevel change will have to rerun network initialization script. Can you give an example where you need that? it is a bit strange, network IP numbers are the same no matter what we do at present. I thought that network would be more complicated. My use case: I maintain a business application consisting of - FreeBSD - several ports - my software and I run this system: a) for development, in a VM on my laptop on my local network; b) for demonstration and customer guided planning, in a VM on my laptop on the customers network, c) for production, on a machine on the customers network, d) for production, in a VM on the laptops of the customers team. The software is the same for all 4, but they differ in services started and in network settings. Having service profiles and network profiles would allow me to have a convenient method of delegating the whole setup to the application: System boots, no services default network, application starts, detects machine role (devel, demo, server, portable), configures the network and starts the appropriate services. As in: I have a configuration file for the application anyway. This configuration file contains the machine role (devel, demo ...) anyway. If I could send this role as a parameter to rc mode role and network and services would be configured accordingly, I could have an identical rc.conf over all roles, and I'd consider that a big plus. Michael ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 20.06.2012, 18:13 Uhr, schrieb Daniel Robbins drobb...@funtoo.org: To add a service to a runlevel, you type rc-update add service runlevelname. To start/stop all services according to runlevel, you type rc. To switch runlevels, you type rc runlevel, like rc mobile. Just to clarify: In OpenRC I can have *arbitrary* runlevels? Not like as I remember from years ago when I used Linux, runlevel 1 2 3 4 5, but any number of default online maintenance, and thus I'd have *sets* of services I could conveniently start and stop together? But there is no possibility of separating base system /etc and ports /usr/local/etc? The separation between the two is something I'd not want to loose. Michael ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 20.06.2012, 22:29 Uhr, schrieb Wojciech Puchar woj...@wojtek.tensor.gdynia.pl: # rc maintenance # rc online this functionality seems useful. That's... not the word I'd have used. I'm sort-of-emulating this using custom scripts quite often, and especially with the stacked runlevel variety, this is something I really would like to have. http://www.funtoo.org/wiki/Stacked_Runlevels shows the possibility of multiple network configs, too, if I read this right, i could have # rc online with 2 children: # rc online-devel vs # rc online-demo to have the same services, but different network settings, without (un)commenting lines in rc.conf before and after the on-site demonstration. ___ 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 ___ 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: Replacing rc(8) (Was: FreeBSD Boot Times)
Am 20.06.2012, 23:42 Uhr, schrieb Freddie Cash fjwc...@gmail.com: On Wed, Jun 20, 2012 at 1:28 PM, Daniel Robbins drobb...@funtoo.org wrote: On Wed, Jun 20, 2012 at 2:22 PM, Daniel Robbins drobb...@funtoo.org wrote: This doesn't change the hard runlevel (3) but it changes the OpenRC logical runlevel. Basically, this convenient system is compatible with traditional linux numerical runlevels but does depend on them. Meant to type: does NOT depend on them. Here is a bit more info: Runlevel-specific conf.d files: http://www.funtoo.org/wiki/Funtoo_Linux_Networking#Alternate_Configs Stacked runlevels (this is a more sophisticated feature than just creating a duplicate, separately-managed runlevel): http://www.funtoo.org/wiki/Stacked_Runlevels To create a separately-managed runlevel, you would just: # mkdir /etc/runlevels/maintenance # rc-update add maintenance svc1 # rc-update add maintenance svc2 # rc-update add maintenance svc1 You could then switch by typing: # rc maintenance Anything not in the maintenance runlevel that is currently running would be stopped, and any new services in maintenance that are not running would be started. There's no need to do a wholesale replacement of the RC system in FreeBSD to support this concept. What you are describing are service profiles. And we already have a single file that describes the default service profile for FreeBSD: /etc/rc.conf. That lists every service that should be started (or stopped). All that's missing is a way to tell the RC system to use a different rc.conf file (like rc.conf.mobile, or rc.conf.wireless or rc.conf.whatever), and to run through the RC setup based on that file. ... and to be able to switch between two configurations at runtime, without taking down services listed active in both configurations preferably. Our current RC system does everything needed except: - parallel execution of items that don't depend on each other - monitor running services and restart them if they crash Compared to all the init/RC systems on Linux, ours has *many* advantages, not the least of which are: - very simple text configuration file - only 2 directories of init scripts to worry about (/etc/rc.d; /usr/local/etc/rc.d) - ability to create generic or global config file (/etc/rc.conf) with local overrides (/etc/rc.conf.local) - ability to see the exact order that things will start (or stop) via rcorder - everything is written in nice, simple, sh We don't need to replace a perfectly working system. Maybe it needs improving, but it doesn't need replacing. Yes. I don't even think it *needs* improving, but service profiles including network profiles would be really nice and worth looking into. If we can get that without loosing the simple text-file-based configuration, the better. ___ 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: cron(8) mis-feature with @reboot long after system startup
Am 26.11.2011, 06:11 Uhr, schrieb Jason Hellenthal jh...@dataix.net: On Fri, Nov 25, 2011 at 10:36:40PM +0100, Christian Kastner wrote: Hi, On 2011-11-25 08:02, Jason Hellenthal wrote: So with that said... is there a way we could actually make this run @reboot only ? Debian's cron[0] and Fedora's cronie[1] have solved this by touching a file on first startup and running @reboot only when this file does not yet exist. Note that while [0] may point to other patches that might be of interest to FreeBSD, they are still WIP (as evident from the linked patch) as we are still in the process of quiltifying our current code base. While this sounds like a perfectly sane way to handle the problem at hand this also introduces a need to write some cleanup code to take care of the file semantics. I think comparing daemon start times to the time a system was booted or similiar would alleviate the need for all that. Maybe a flag for @reboot -s seconds seconds after boottime to allow running @reboot jobs. And set the default to 3600 seconds. At least this would allow adjustment for those startup processes that may take some considerable time before multiuser mode is entered. Just some thought. I really don't think we need to go the route of using files to store information when there is enough information available already via syscall's. If system startup were to be unusually delayed (dhcp or nfs trouble eg), $time_period might have passed when cron starts, so there would have to be some notifying mechanism for @reboot jobs not being run, and operator action would be required. One could cron restart within $time_period and run @reboot twice. I don't like this idea. In my bikeshed, @reboot should be called @cronstart, but it shouldn't because of uniformity across OSs. The cron manpage should reflect the actual behaviour (already patched in svn), and all definitely only on boot-scripts should go in local/etc/rc.d. Michael ___ 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
