| View previous topic :: View next topic |
| Author |
Message |
heini
n00b
Joined: 20 Sep 2002
Posts: 32
|
 Posted: Thu Mar 13, 2008 7:35 am Post subject: cfg-update doesn't preserve file permissions |
 |
|
Hi,
after every update of app-admin/sudo and the following cfg-update run, the permissions of /etc/sudoers have changed from 0440 to 0644 so that the next time sudo is used it refuses to run, complaining about wrong permissions. I've verified that the permission change doesn't come from the installation/update of the package, but indeed from cfg-update.
Bye...
Dirk |
|
| Back to top |
|
 |
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Thu Mar 13, 2008 7:54 pm Post subject: |
|
|
Hi Dirk,
Can you emerge sudo again and then run:
ls -al /etc/sudoers
ls -al /etc/._cfg0000_sudoers
cfg-update -udv
ls -al /etc/sudoers
and post the above output here?
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
heini
n00b
Joined: 20 Sep 2002
Posts: 32
|
| Posted: Fri Mar 14, 2008 10:42 am Post subject: |
|
|
| xentric wrote: | Can you emerge sudo again and then run:
ls -al /etc/sudoers
ls -al /etc/._cfg0000_sudoers |
Sure. Before re-install:
| Code: | # ls -al /etc/sudoers
-r--r----- 1 root root 1608 14. Mär 11:27 /etc/sudoers
|
Permissions are correct.
After re-install (using paludis -i sudo):
| Code: | # ls -al /etc/sudoers
-r--r----- 1 root root 1608 14. Mär 11:27 /etc/sudoers
# ls -al /etc/._cfg0000_sudoers
-r--r----- 1 root root 1612 14. Mär 11:35 /etc/._cfg0000_sudoers
|
Permissions are still correct.
| Code: | # cfg-update -udv
<show_debug_info>
version = 1.8.2-r1
merge_tool_name = kdiff3
merge_tool = /usr/bin/kdiff3
xxdiff_style = --style Keramik
index_file = /var/lib/cfg-update/checksum.index
hosts_file = /etc/cfg-update.hosts
portage_hook = /etc/portage/bashrc
paludis_hook = /usr/share/paludis/hooks/install_all_pre/cfg-update.bash
pkg_manager = Portage
pkg_db = /var/db/pkg
install_log = /var/log/emerge.log
find_string = ::: completed emerge
backup_path = /var/lib/cfg-update/backups
enable_backups = yes
enable_stage1 = yes
enable_stage2 = yes
enable_stage3 = yes
enable_stage4 = yes
enable_stage5 = yes
config_new = ._cfg????_*
rm_new = \._cfg...._
temp_new = ._temp-new-cfg_*
backup_new = ._new-cfg_*
restore_new = ._cfg0000_*
rm_old = \._old-cfg_
temp_old = ._temp-old-cfg_*
backup_old = ._old-cfg_*
restore_old = *
merged = *.merge
opt_i = 0
opt_f = 0
opt_s = 0
opt_l = 0
opt_u = 1
opt_b = 0
opt_r = 0
opt_a = 0
opt_m = 0
opt_d = 1
opt_p = 0
opt_v = 1
opt_h = novalue
opt_t = novalue
opt_help = 0
opt_test_code = 0
opt_ebuild = 0
opt_check_hosts = 0
opt_mount_hosts = 0
opt_unmount_hosts = 0
opt_check_packages = 0
opt_move_backups = 0
opt_disable_portage_hook = 0
opt_disable_paludis_hook = 0
opt_optimize_backups = 0
mount_count = 1
mount_first = 0
mount_last = 0
mount_point[0] = ""
</show_debug_info>
<check_hooks>
Paludis hook is already enabled...
Portage hook is already enabled...
</check_hooks>
<check_tool>
merge_tool = /usr/bin/kdiff3
merge_tool_name = kdiff3
tool_supports_2way = yes
tool_supports_3way = yes
tool_saves_mergefile_when_aborted = yes
tool_needs_gui = yes
</check_tool>
<root_only>
id -u
</root_only>
<update_files>
Searching for updates...
<find_updates>
<find_protected_dirs>
portageq config_protect
</find_protected_dirs>
find /etc -name '._cfg????_*' | sort
find /usr/kde/3.5/env -name '._cfg????_*' | sort
find /usr/kde/3.5/share/config -name '._cfg????_*' | sort
find /usr/kde/3.5/shutdown -name '._cfg????_*' | sort
find /usr/share/config -name '._cfg????_*' | sort
</find_updates>
<< Scheduler >> queueing automatic updates...
<schedule_automatic_updates>
<prepare_filenames_for_updating>
host_path =
backup_path = /var/lib/cfg-update/backups
path = /etc/
file1 = /etc/sudoers
file2 = /etc/._cfg0000_sudoers
file3 = /var/lib/cfg-update/backups/etc/._old-cfg_sudoers
file4 = /var/lib/cfg-update/backups/etc/._new-cfg_sudoers
file5 = /etc/sudoers.merge
file6 = /var/lib/cfg-update/backups/etc/._temp-old-cfg_sudoers
file7 = /var/lib/cfg-update/backups/etc/._temp-new-cfg_sudoers
</prepare_filenames_for_updating>
<determine_state>
md5sum /etc/sudoers | cut -d" " -f1
MD5 checksum of current config file : 3e869ed96c33b4428df14fadb6cf3d57
grep "/etc/sudoers " /var/lib/cfg-update/checksum.index | cut -d" " -f2
MD5 checksum in the checksum-index :
State of the current file : Custom File
Ancestor file available : true
Merge conflict detected : false
Executable file : no
</determine_state>
</schedule_automatic_updates>
<update_stage1>
<< Stage1 >> 0 files in queue for automatic replacing, skipping...
</update_stage1>
<update_stage2>
<< Stage2 >> 0 files in queue for automatic 3-way merging, skipping...
</update_stage2>
<find_updates>
<find_protected_dirs>
portageq config_protect
</find_protected_dirs>
find /etc -name '._cfg????_*' | sort
find /usr/kde/3.5/env -name '._cfg????_*' | sort
find /usr/kde/3.5/share/config -name '._cfg????_*' | sort
find /usr/kde/3.5/shutdown -name '._cfg????_*' | sort
find /usr/share/config -name '._cfg????_*' | sort
</find_updates>
<< Scheduler >> queueing manual updates, including canceled automatic updates...
<schedule_manual_updates>
<prepare_filenames_for_updating>
host_path =
backup_path = /var/lib/cfg-update/backups
path = /etc/
file1 = /etc/sudoers
file2 = /etc/._cfg0000_sudoers
file3 = /var/lib/cfg-update/backups/etc/._old-cfg_sudoers
file4 = /var/lib/cfg-update/backups/etc/._new-cfg_sudoers
file5 = /etc/sudoers.merge
file6 = /var/lib/cfg-update/backups/etc/._temp-old-cfg_sudoers
file7 = /var/lib/cfg-update/backups/etc/._temp-new-cfg_sudoers
</prepare_filenames_for_updating>
<determine_state>
md5sum /etc/sudoers | cut -d" " -f1
MD5 checksum of current config file : 3e869ed96c33b4428df14fadb6cf3d57
grep "/etc/sudoers " /var/lib/cfg-update/checksum.index | cut -d" " -f2
MD5 checksum in the checksum-index :
State of the current file : Custom File
Ancestor file available : true
Merge conflict detected : false
Executable file : no
</determine_state>
</schedule_manual_updates>
<update_stage3>
<< Stage3 >> 0 files in queue for manual 3-way merging, skipping...
</update_stage3>
<update_stage4>
<< Stage4 >> 1 files in queue for manual 2-way merging, starting...
<prepare_filenames_for_updating>
host_path =
backup_path = /var/lib/cfg-update/backups
path = /etc/
file1 = /etc/sudoers
file2 = /etc/._cfg0000_sudoers
file3 = /var/lib/cfg-update/backups/etc/._old-cfg_sudoers
file4 = /var/lib/cfg-update/backups/etc/._new-cfg_sudoers
file5 = /etc/sudoers.merge
file6 = /var/lib/cfg-update/backups/etc/._temp-old-cfg_sudoers
file7 = /var/lib/cfg-update/backups/etc/._temp-new-cfg_sudoers
</prepare_filenames_for_updating>
<determine_state>
md5sum /etc/sudoers | cut -d" " -f1
MD5 checksum of current config file : 3e869ed96c33b4428df14fadb6cf3d57
grep "/etc/sudoers " /var/lib/cfg-update/checksum.index | cut -d" " -f2
MD5 checksum in the checksum-index :
State of the current file : Custom File
Ancestor file available : true
Merge conflict detected : false
Executable file : no
</determine_state>
<make_temp_backups>
cp -pP "/etc/sudoers" "/var/lib/cfg-update/backups/etc/._temp-old-cfg_sudoers"
cp -pP "/etc/._cfg0000_sudoers" "/var/lib/cfg-update/backups/etc/._temp-new-cfg_sudoers"
</make_temp_backups>
<md5sum>
md5sum /etc/sudoers | awk '{ print $1 }'
</md5sum>
<md5sum>
md5sum /etc/._cfg0000_sudoers | awk '{ print $1 }'
</md5sum>
(1/1) /etc/sudoers *Custom File
<show_warning>
* YOU ARE ABOUT TO UPDATE A CUSTOM FILE. YOU SHOULD ASK YOURSELF
* WHERE DOES IT COME FROM AND WHAT HAPPENDS WHEN YOU REPLACE IT?
* PORTAGE DID NOT INSTALL THE CURRENT FILE, MOST LIKELY IT HAS BEEN
* CREATED AFTER INSTALLATION AND IT MAY CONTAIN CUSTOM SETTINGS.
</show_warning>
Press [y] - to merge the current file and the ._cfg0000_* file with kdiff3
Press [s] - to skip this update (to investigate first, and try again later)
Press [q] - to quit cfg-update immediately
Merge manually with file : /etc/._cfg0000_sudoers ? [y|s|q]
<readkey>
y
</readkey>
<tool_intro>
In kdiff3 you select the lines that you want to keep.
When done, click the save button and exit kdiff3!
When you exit kdiff3, cfg-update will finish the update...
</tool_intro>
<launch_tool>
<check_gui>
merge_tool = /usr/bin/kdiff3
merge_tool_name = kdiff3
tool_needs_gui = yes
xhost &>/dev/null; echo 0
</check_gui>
/usr/bin/kdiff3 /etc/sudoers /etc/._cfg0000_sudoers -o /etc/sudoers.merge
kbuildsycoca running...
</launch_tool>
<update_merge_complete>
Replacing it with /etc/sudoers.merge
cp -pP "/etc/sudoers.merge" "/etc/sudoers"
rm -f "/etc/sudoers.merge"
rm -f "/etc/._cfg0000_sudoers"
cp -pP "/var/lib/cfg-update/backups/etc/._temp-old-cfg_sudoers" "/var/lib/cfg-update/backups/etc/._old-cfg_sudoers"
rm -f "/var/lib/cfg-update/backups/etc/._temp-old-cfg_sudoers"
cp -pP "/var/lib/cfg-update/backups/etc/._temp-new-cfg_sudoers" "/var/lib/cfg-update/backups/etc/._new-cfg_sudoers"
rm -f "/var/lib/cfg-update/backups/etc/._temp-new-cfg_sudoers"
Update complete...
</update_merge_complete>
</update_stage4>
<update_stage5>
<< Stage5 >> 0 files in queue for manual updating, skipping...
</update_stage5>
</update_files>
<done>
<find_updates>
<find_protected_dirs>
portageq config_protect
</find_protected_dirs>
find /etc -name '._cfg????_*' | sort
find /usr/kde/3.5/env -name '._cfg????_*' | sort
find /usr/kde/3.5/share/config -name '._cfg????_*' | sort
find /usr/kde/3.5/shutdown -name '._cfg????_*' | sort
find /usr/share/config -name '._cfg????_*' | sort
</find_updates>
All files have been updated...
</done>
|
| Quote: | ls -al /etc/sudoers
|
| Code: | # ls -al /etc/sudoers
-rw-r--r-- 1 root root 1608 14. Mär 11:36 /etc/sudoers
|
Now permissions are wrong.
Bye...
Dirk |
|
| Back to top |
|
|
heini
n00b
Joined: 20 Sep 2002
Posts: 32
|
| Posted: Fri Mar 14, 2008 10:59 am Post subject: |
|
|
| heini wrote: | | Code: |
<update_merge_complete>
Replacing it with /etc/sudoers.merge
cp -pP "/etc/sudoers.merge" "/etc/sudoers"
|
|
I'd say this is the reason. kdiff 3 creates a new file (/etc/sudoers.merge), which is then copied over.
Bye...
Dirk |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Sun Mar 16, 2008 10:50 am Post subject: |
|
|
| heini wrote: | | I'd say this is the reason. kdiff 3 creates a new file (/etc/sudoers.merge), which is then copied over. |
Yes, and kdiff3 respects the umask 022 setting.
I guess I'll have to add some code that checks the file permissions before the update and duplicates that after the update.
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
XenoTerraCide
Veteran
Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA
|
| Posted: Mon Mar 31, 2008 3:13 am Post subject: |
|
|
I feel like being lazy so here's the conversation from irc. the short is I have tac: write errors in pkgcore that I'm told are cfg-update
| Quote: |
[22:52] <xenoterracide_> tac: write error
[22:53] <xenoterracide_> I noticed some other ones as well
[22:53] <xenoterracide_> but din't record them
[22:53] <xenoterracide_> ferringb: said tac had something to do with twisted way up there...
[22:53] <mjrosenb> having actual error messages usually helps
[22:54] <xenoterracide> mjrosenb: tac: write error is the actual message from my terminal
[22:54] <xenoterracide> I just know I saw another one that I didn't make note of
[22:56] <xenoterracide> TFKyle asked me to look for segfaults in dmesg
[22:57] <xenoterracide> conftest[29531]: segfault at 0804c000 eip b7ead87c esp bfe856b8 error 6
[22:57] <xenoterracide> I found that
[23:01] <ferringb> xenoterracide: it's not pkgcore... it's cfg-update
[23:01] <agaffney> xenoterracide: he was wrong about it being related to twisted
[23:01] <ferringb> tac is a format used by twisted, it's also a binary for reversing the lines of a file, gotten from coreutils
[23:01] <agaffney> he just didn't know what it was
[23:01] <agaffney> yes, that 
[23:02] <xenoterracide> ferringb: yeah I know the second one
[23:02] <ferringb> xenoterracide: check your bashrc. they try to use old style bashrc hooking which is daft, since pre_pkg_setup has existed for literally ~2 years 
|
_________________
I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help. |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Mon Mar 31, 2008 10:04 pm Post subject: |
|
|
| XenoTerraCide wrote: | | I feel like being lazy so here's the conversation from irc. the short is I have tac: write errors in pkgcore that I'm told are cfg-update |
Yes, cfg-update uses tac to find the last merged package in the Portage logfile /var/log/emerge.log
But cfg-update expects the format that portage uses to write information to this file...
So if you start using a drop-in replacement (pkgcore) for which cfg-update has no support, and pkgcore doesn't write to the emerge.log in the same format as portage did, then you may experience weird things.
I have never tested cfg-update with pkgcore.
I don't know how/where pkgcore stores it's MD5 checksums.
I don't know the format of the pkgcore emerge log, is it also /var/log/emerge.log?
I'm guessing that pkgcore uses /etc/portage/bashrc just like portage does (as the hook to cfg-update is stored there).
So please run "cfg-update --disable-portage-hook" to disable the hook that runs cfg-update --index during emerging with pkgcore.
You can probably continue to use cfg-update without index updates (during emerging).
It will still do automatic 3-way merges and manual merging, only the automatic replacing of unmodified files will not work anymore.
But you will need to specify the special option --ebuild everytime otherwise cfg-update will automatically try to re-enable the hook.
So you can only use it like this: "cfg-update --ebuild -l" and "cfg-update --ebuild -u"... until a new version of cfg-update supports pkgcore.
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
XenoTerraCide
Veteran
Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA
|
| Posted: Tue Apr 01, 2008 12:46 am Post subject: |
|
|
I can't answer the things you are unsure of. Try asking them on freenode #pkgcore the people their are always helpful. I think they said somewhere that pkgcore doesn't use /etc/portage/bashrc like portage does. Don't ask me how however. I'm just testing pkgcore. Thus far I like it better than paludis, (it was originally intended to be portage 3) but it may not be as far along yet. It's a fast install if you wanted to test it yourself.
_________________
I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help. |
|
| Back to top |
|
|
XenoTerraCide
Veteran
Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA
|
| Posted: Sun Apr 13, 2008 12:37 am Post subject: |
|
|
pkgcore doesn't use emerge.log yet... opening a bug about it as no (good) work around has been presented.
_________________
I don't hang out here anymore, try asking on http://unix.stackexchange.com/ if you want my help. |
|
| Back to top |
|
|
xentric
Guru
Joined: 16 Mar 2003
Posts: 410
Location: Netherlands
|
| Posted: Fri Jul 11, 2008 7:30 pm Post subject: |
|
|
******************************************************************************
NOTE TO ALL CFG-UPDATE USERS:
After 5 years I'm finally looking for someone capable of fully adopting cfg-update as I do not have the time to properly support it anymore. I will fix all remaining bugs in week 31 and write some documentation to enable someone else to continue developing it further...
By the way, all those years I have wondered how many people are actually using cfg-update. I still have no clue!
I would really, really, really appreciate it if all you guys out there would just send a shout to xentric@zeelandnet.nl with your name or nickname and your location, just for the fun of it and to get an idea what the minimal size of the userbase is.
Drop me an e-mail on the same address if you're interested in adopting cfg-update.
Regards,
Stephan van Boven
For more details see: app-portage/cfgupdate - installation instructions
******************************************************************************
_________________
When all else fails, read the manual...
Registered Linux User #340626 |
|
| Back to top |
|
|
Uzytkownik
Guru
Joined: 31 Oct 2004
Posts: 399
Location: Bay Area, US
|
| Posted: Mon Sep 20, 2010 12:39 pm Post subject: |
|
|
Bug still present in 2010.
_________________
I've probably left my head... somwhere. Please wait untill I find it. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Oct 02, 2011 11:00 am Post subject: Taking over maintenance |
|
|
| FYI - I'll be taking over maintenance of this package in portage. |
|
| Back to top |
|
|
Uzytkownik
Guru
Joined: 31 Oct 2004
Posts: 399
Location: Bay Area, US
|
| Posted: Sun Oct 02, 2011 8:35 pm Post subject: Re: Taking over maintenance |
|
|
| rich0 wrote: | | FYI - I'll be taking over maintenance of this package in portage. |
Does it mean that package is maintained despite note in package.mask (or rather from now)?
_________________
I've probably left my head... somwhere. Please wait untill I find it. |
|
| Back to top |
|
|
rich0
Developer
Joined: 15 Sep 2002
Posts: 161
|
| Posted: Sun Oct 02, 2011 8:42 pm Post subject: Re: Taking over maintenance |
|
|
| Uzytkownik wrote: | | rich0 wrote: | | FYI - I'll be taking over maintenance of this package in portage. |
Does it mean that package is maintained despite note in package.mask (or rather from now)? |
Yes, I unmasked it. In fact, ~arch will get an upgrade once they sync (just fixes to one or two outstanding bugs, and merging everything into the upstream repository and putting it on github).
So far the list of enhancements people seem to be interested in are support for beediff and earlier options to replace/delete. From looking at the code I think both will be simple to implement. I suspect I'll add them both in the next version to keep everybody from getting three updates in a week.
I also plan to stabilize new versions after 30 days, so you won't be stuck on ~arch.
What I don't know is how many people are using this package, but I'm happy to see a little activity here. Hopefully the mask didn't scare away too many before I got a chance to take over. Dispatch-conf has come a long way since 2008, but I still see this as more useful. |
|
| Back to top |
|
|
Uzytkownik
Guru
Joined: 31 Oct 2004
Posts: 399
Location: Bay Area, US
|
| Posted: Sun Oct 02, 2011 8:48 pm Post subject: Re: Taking over maintenance |
|
|
| rich0 wrote: | | Uzytkownik wrote: | | rich0 wrote: | | FYI - I'll be taking over maintenance of this package in portage. |
Does it mean that package is maintained despite note in package.mask (or rather from now)? |
Yes, I unmasked it. In fact, ~arch will get an upgrade once they sync (just fixes to one or two outstanding bugs, and merging everything into the upstream repository and putting it on github).
So far the list of enhancements people seem to be interested in are support for beediff and earlier options to replace/delete. From looking at the code I think both will be simple to implement. I suspect I'll add them both in the next version to keep everybody from getting three updates in a week.
I also plan to stabilize new versions after 30 days, so you won't be stuck on ~arch.
What I don't know is how many people are using this package, but I'm happy to see a little activity here. Hopefully the mask didn't scare away too many before I got a chance to take over. Dispatch-conf has come a long way since 2008, but I still see this as more useful. |
cfg-update just work for me (the only problem was the permission for sudoers but I use mainly su anyway) so I saw no point in troubleshooting. I'm installing after uninstall right now.
_________________
I've probably left my head... somwhere. Please wait untill I find it. |
|
| Back to top |
|
|
|
Portage & Programming
