Bugs for Sorcery are reported here

[bugzilla-daemon AT bugs.sourcemage.org]

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.