Skip to Content.
Sympa Menu

sm-sorcery-bugs - [SM-Sorcery-Bugs] [Bug 13400] symlinks for config files should not be reaped

sm-sorcery-bugs AT lists.ibiblio.org

Subject: Bugs for Sorcery are reported here

List archive

Chronological Thread  
  • From: bugzilla-daemon AT bugs.sourcemage.org
  • To: sm-sorcery-bugs AT lists.ibiblio.org
  • Subject: [SM-Sorcery-Bugs] [Bug 13400] symlinks for config files should not be reaped
  • Date: 25 Feb 2007 21:45:02 -0000

http://bugs.sourcemage.org/show_bug.cgi?id=13400





------- Additional Comments From acedit AT armory.com 2007-02-25 15:45 -------
(In reply to comment #5)
> Well, there was no actual loss of data, but the LDAP config was broken and
> thus all user (except root) authentification on the system using pam_ldap
> and
> nss_ldap.
> It is unnecessary breakage and I really hope it is fixed some time.
> Until then, I guess my friend will resort to just not touching that install
> and not updating.

You dont do live untested updates to critical services on production servers.
Period. Ask any respected system admin. Often you have a mirror system you
test
the update on, before going live. You can ask emrys about good system
administration practices.

> His experience now is that when you update, things break -
> even when you monitor the update and ask all questions with thought.
> I hoped to convince him to use SMGL also to have a way to have updates
> managed
> (to be done at all)... perhaps I'm to eager in that care for one potential
> (and capable) supporter.

If your friend expects no less than perfection, he shouldn't be using linux at
all. No distro I know of can do seemless perfect live updates like you
describe.
Yea, when you update, things break, thats nothing unique to smgl. If he
expected
perfection out of smgl, then either you oversold it, or he has unrealistic
expectations of linux distros, is his current distro perfect? I doubt it. More
likely he's worked around its shortcomings to the point he doesn't notice
them.

>
> And my patch... it was the simplest resolution that occured to me. As I
> don't
> see a point in treating symlinks any differently at all, I didn't try to.

Its nothing personal. The patch serves as an indicator of what you consider
proper behavior. I have to explore the various behaviors, potential pitfalls,
etc. first.

> There may be a reason... but this function just deletes all the stuff.

Yes, there may be a reason, and I have to figure out if there is or not.
Whether
one previously known or not.

> The only change now is that the symlinks are considered to be possible
> config
> files where they all were deleted right away before.
> I don't quite understand your concern

Its my job to look critically at all changes, its nothing personal. This is
uncharted territory. Be mindful that dispel runs as root on your box. Caution
is
necessary.

>
> > It treats *all* symlinks to files as files,
> > whether or not they're config files or not.
>
> Either we treat symlinks to files differently or not. I don't see the point
> where you could limit the treatment and not treat '*all*' file sylmlinks
> the
> same.

There are four cases, a file can be a symlink, or not, and be a config file,
or
not. Two bits, four combinations. Your patch removes the first distinction. I
suggest that there may be problems from removing that distinction, and, that
there might be use in making it. Its my job to consider what those problems
might be.

>
> Anyway, perhaps someone remembers why the code treats the symlinks
> differently... or we find a reason... or we change it.

Of course, theres never been any intent to not fix it. You dont need to repeat
this dialog on every occasion. -- Just because I have a different perspective
on
severity or resolution doesnt mean I dont want the problem resolved. Im not
your
enemy.


--
Configure bugmail: http://bugs.sourcemage.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.




Archive powered by MHonArc 2.6.24.

Top of Page