[07:52] <exitdescription> ok! can anyone tell me again why there's upstart and not the usual startup scripts?
[08:03] <exitdescription> hi there, can anyone tell me where the upstart scripts are located?
[08:06] <exitdescription> okie found it
[08:06] <exitdescription> thanks!
[14:32] <ralfgro_> howdy!
[14:32] <ralfgro_> I'm trying to write an upstart script that needs user interaction
[14:33] <ralfgro_> it should run after network is up and before any user can log in
[14:34] <ralfgro_> so the parallel upstart boot process should wait until this script has finished
[14:34] <ralfgro_> I haven't found much on this topic
[14:42] <mbiebl> ralfgro_: requiring user input during boot is a bad idea
[14:44] <ion> Interface with plymouth. Its job is to multiplex user interaction for processes.
[14:45] <ralfgro_> well, the problem is that not all system are running a DM
[14:45] <ralfgro_> we want to update clients during the boot process
[14:46] <ralfgro_> but the user has the option to say no
[14:46] <ralfgro_> that'S the policy, user can discard updates one time
[14:47] <ralfgro_> and we don't have simple laptops or desktops
[14:47] <ralfgro_> some systems can't be updated after the have bootet
[14:47] <ralfgro_> so we need a way to do it right after network is up
[14:48] <ralfgro_> it's getting worse, it has to work with old sysvinit (lenny), insserv (squeeze) and upstart (ubuntu)
[14:49] <mbiebl> sysvinit/insserv is basically the same
[14:49] <ralfgro_> but at the moment I'm trying to find out how it could be done with upstart
[14:51] <ralfgro_> I haven't found a way to write an upstart script that simply halts the boot process. I know that's not the goal of upstart, but is this possible?
[14:51] <mbiebl> ralfgro_: you can ship a sysvinit/LSB script
[14:51] <mbiebl> upstart still supports sysv init scripts
[14:53] <ralfgro_> do you have a link for this?
[14:53] <ralfgro_> http://upstart.ubuntu.com/
[14:53] <ralfgro_> was not very helpful
[14:54] <mbiebl> ralfgro_: if you want to run it before a user can login you have a problem
[14:54] <mbiebl> because the gdm init script triggers on the filesystem and dbus events
[14:55] <ralfgro_> I've seen that in the dgm/kdm scripts
[14:56] <mbiebl> you could block dbus from starting 
[14:56] <mbiebl> by writing a job that has "start on starting dbus"
[14:56] <ralfgro_> can I emit something from an sysv scrip?
[14:56] <ion> Or just block gdm by ‘start on starting gdm’
[14:56] <mbiebl> sure
[14:56] <ralfgro_> then I could add that to the start on ... part
[14:57] <mbiebl> ion: he would also need to block the gettys
[14:57] <mbiebl> and gdm is started rather late during boot
[14:57] <mbiebl> so a lot of services are already running
[14:57] <ralfgro_> I begin to think it was not the best idea to do updates while booting
[14:58] <mbiebl> ion: does gdm respect /etc/nologin?
[14:58] <ion> dunno
[14:58] <plautrba> in fedora i would use something like 'start on starting start-ttys, console owner, task'
[14:58] <mbiebl> (looking at /etc/pam.d/nologin, it should)
[14:59] <mbiebl> /etc/pam.d/gdm, I meand
[14:59] <ralfgro_> kdm: auth       required     pam_nologin.so
[14:59] <mbiebl> ralfgro_: creating a file /etc/nologin should then prevent users from being able to login
[15:00] <ralfgro_> hm, but if gdm is started they don't see the dialog 
[15:00] <ralfgro_> Update now: y/n....
[15:01] <ralfgro_> this is getting complicated
[15:01] <mbiebl> ralfgro_: why don't you use the regular update mechanisms
[15:01] <ralfgro_> we use puppet for regular desktops/laptops
[15:01] <mbiebl> so?
[15:01] <ralfgro_> but we have a lot of systems that can only be updataes before they are running
[15:01] <mbiebl> example?
[15:02] <ralfgro_> so the people that use these systems needed a special solution
[15:02] <ralfgro_> some systems are build in cars
[15:02] <ralfgro_> most of the time they are only reachable by net during boot up
[15:03] <ralfgro_> others start calculations and can't be updated during normal run time
[15:03] <ralfgro_> so need a solution that works for them
[15:04] <mbiebl> so if the system is up and running it is cut of the network?
[15:04] <ralfgro_> probably
[15:05] <mbiebl> I'd change my deployment to use something like fai or d-i preseeding to have up-to-date systems after installation
[15:05] <ralfgro_> the biggest chance is during boot tiem
[15:05] <ralfgro_> we install our systems with dai
[15:05] <ralfgro_> fai
[15:05] <ralfgro_> but we can't use softupdates to keep them up to date
[15:06] <ralfgro_> it is very complicated here, everything is a moving target
[15:06] <ralfgro_> after install, the systems are modified from the users (yes they have roo). and yes, it's a nightmare
[15:07] <ralfgro_> anyway, we have to find a way to install security updates
[15:07] <mbiebl> I'd try the nologin + start on starting gdm approach then
[15:07] <ralfgro_> desktops/laptops get them triggered by puppert at 4am
[15:07] <mbiebl> (although it is not pretty)
[15:08] <ralfgro_> ok, I'll have a look into that
[15:08] <mbiebl> you probably need "console owner"
[15:08] <mbiebl> if you use want to prompt via a shell script
[15:09] <ion> Better to use plymouth.
[15:09] <mbiebl> if they use it, yeah
[15:10] <ralfgro_> on ubuntu yes, ii  plymouth                            0.8.2-2ubuntu2.2  
[15:10] <ralfgro_> but not on debian AFAIR
[15:11] <ralfgro_> the goal should be somethin that runs on both
[15:11] <mbiebl> it is not mandatory, but installable
[15:12] <ralfgro_> maybe it would be better and easier to start something right after the user logged in with *GM or console
[15:12] <ralfgro_> **DM
[15:12] <mbiebl> ralfgro_: it should be easier on Debian as the boot process is still linear
[15:13] <mbiebl> sure, you can use a desktop autostart file for that
[15:15] <mbiebl> ralfgro_: just run apt-get update during boot
[15:15] <mbiebl> update-manager should automatically prompt you if there are new updates availabe
[15:16] <ralfgro_> we don't want to use update-manager
[15:16] <ralfgro_> we need some more logging
[15:16] <mbiebl> like /var/log/dpkg.log ?
[15:17] <ralfgro_> so we will start our own script, if the user decides to install updates on his own, that's fine. but we can't relay on that
[15:17] <ralfgro_> so the user can start update-manager, but we trigger our own script
[15:18] <mbiebl> I still don't understand why you want to cook up your own solution, but ok
[15:18] <ralfgro_> as I wrote above, the user have root right. which is needed because the clients are development machines etc.
[15:18] <ralfgro_> so sometime they change the sources.list
[15:19] <mbiebl> i don't see a problem here
[15:19] <ralfgro_> because they don't have access to our network when the are abroud
[15:20] <mbiebl> prompting during boot doesn't solve that problem
[15:20] <ralfgro_> but these sources are not reachable from the company network when they are back
[15:21] <ralfgro_> in the script we use differnt sources lists witch are fixed
[15:21] <ralfgro_> but trust me, it's compicated and we just try to do what is possible in this environment
[15:22] <ralfgro_> thanks for the pointers so far
[16:02] <JanC> why not have a sources list with a hostname that always resolves to a working IP depending on whether you are inside or outside the company LAN?