wirteable config files path
by Johan Cwiklinski
Hello,
I'm the maintainer of BackupPC, a backup software written in perl.
I have some SELinux issues actually, and need your advices to create the
relevant package.
BackupPC provides a web interface that needs write access to its config
files (actually located under /etc/BackupPC). Problem is that /etc
should not be writeable.
So my question is : where should I place those config files ? Config
files should be located under /etc, but /etc should be readonly.
/var/lib/backuppc would be a good idea, but it's not relevant for config
files.
Solutions I see :
1- keep config files under /etc, and make them writeable from apache,
2- simply move config files to /var/lib/backuppc
3- move config files to /var/lib/backuppc, and then create a symlink to
this path in /etc
What would you advice ?
Regards,
Johan
15 years, 7 months
- 2
- 2
using yum/repoquery to provide dependency trees
by Peter Robinson
Hi All,
I just installed rawhide (F10 Alpha LiveCD + yum update) into a
virtual machine to play around with what I could get into a 4GB
location like you'd get on a some of the netbooks out there to see
what sort of milage you'd get. Doing a standard install by booting the
LiveCD, selecting the install to hard disk icon and then selecting all
the the defaults it installed in an lvm vol of around 2.3 gig with the
remaining going to swap. It installed but basically I then had space
issues when trying to do a 'yum update'... interesting!
Anyway I'm wondering if there's a way to some dep tree style bits with
packages that are installed to see what causes the dependencies of
what is actually installed. EG if I do a 'yum remove perl' it
basically wants to uninstall gnome and a lot more but it would be nice
to be able to see exactly what installed packages depend on perl or
perl-Pop-Simple for example.
Peter
15 years, 7 months
- 3
- 3
system autodeath
by Seth Vidal
A friend forwarded me this blog:
http://www.gdt.id.au/~gdt/blog/linux/autodeath.1024px
and I wondered if it would be something to consider for fedora releases.
This would NOT be as a default, but as a package you can install, if you
wish, to drop the route on your box after whatever expiration date. We
can set the release date in a file in the package and key from there.
If the package was included in a fedora repo we could have it have a
death date of whenever the release started + 14months (some wiggle room
for release slips) for example.
Any thoughts?
-sv
--
I only speak for me.
15 years, 7 months
- 23
- 44