Hide Forgot
[root@localhost etc]# cat /etc/rc.local # This conditionally runs Audrey if it exists [ -f /usr/bin/audrey ] && /usr/bin/audrey [root@localhost etc]# ls /var/log/audrey.log ls: cannot access /var/log/audrey.log: No such file or directory [root@localhost etc]# ls -larht /etc/rc.local -rw-r--r--. 1 root root 89 Jan 30 18:57 /etc/rc.local My hunch is that because f16 don't use /etc/rc.local by default anymore, it needs a chmod a+x in order for it to run during startup.
I suspect this is something that needs to be fixed in imagefactory (i.e., imgfac creates the rc.local file, so I think it probably needs to set the perms on the file, too)
dgao provided the credentials to the test instance. I've successfully run the Audrey Agent from the command line. /etc/rc.local is not executable [root@localhost ~]# ls -aFl /etc/rc.local -rw-r--r--. 1 root root 89 Jan 30 18:57 /etc/rc.local From the Fedora 16 release notes: --------------------------------- http://docs.fedoraproject.org/en-US/Fedora/16/html/Release_Notes/sect-Release_Notes-Changes_for_Sysadmin.html I've found: ----------- 3.2.4. rc.local no longer packaged The /etc/rc.d/rc.local local customization script is no longer included by default. Administrators who need this functionality merely have to create this file, make it executable, and it will run on boot. Upgrades are not affected by this change. The solution seem to be that when ImageFactory adds the invocation of the Audrey Agent to /etc/rc.local that it also has to make /etc/rc.local executable. Reassigning to Ian McLeod <imcleod>
Joe and Greg, I believe we are all in violent agreement that our current method of smearing Audrey enablers between the factory and Audrey itself is sub-optimal. I know Joe and I have explicitly discussed having the Audrey RPM put in place it's own startup script, ideally through the well established /etc/init.d mechanism. Forcing the executable flag on our newly created rc.local seems like yet another hack to support this old scheme. If it is essential that we support F16 as an Audrey target in 1.0, I can, of course, fix this with a few lines of patch. What I'd much rather see is a migration to an Audrey RPM that does it's own boot-time startup and does not depend on us appending a line to rc.local in the factory. Thoughts?
(In reply to comment #3) > Joe and Greg, > > I believe we are all in violent agreement that our current method of smearing > Audrey enablers between the factory and Audrey itself is sub-optimal. I know > Joe and I have explicitly discussed having the Audrey RPM put in place it's own > startup script, ideally through the well established /etc/init.d mechanism. > > Forcing the executable flag on our newly created rc.local seems like yet > another hack to support this old scheme. > > If it is essential that we support F16 as an Audrey target in 1.0, I can, of > course, fix this with a few lines of patch. > > What I'd much rather see is a migration to an Audrey RPM that does it's own > boot-time startup and does not depend on us appending a line to rc.local in the > factory. > > Thoughts? agreed. And this is in the works but for post 1.0 For 1.0 I believe this should be fixed in ImageFactory.
My vote would be to not use imagefactory for laying down the rc.local config for audrey. This might help in several areas.. that I wont mention in this bug to muck up the conversation
Lads, A quick fix is available here: https://github.com/aeolusproject/imagefactory/tree/audrey_hack17 If this is found to be acceptable I'll apply it to the 1.0 release branch.
(In reply to comment #6) > Lads, > > A quick fix is available here: > > https://github.com/aeolusproject/imagefactory/tree/audrey_hack17 > > If this is found to be acceptable I'll apply it to the 1.0 release branch. Please apply to 1.0 branch.
Done
Reassigning to proper 'aeolus-audrey-agent' component.
Fedora issue, so we are dropping from 1.1.0
No longer an issue as audrey now run in its own systemd/systemV script. Verified...
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHEA-2012-1516.html