Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
app-portage/cfg-update - troubleshooting
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
heini
n00b
n00b


Joined: 20 Sep 2002
Posts: 32

PostPosted: Thu Mar 13, 2008 7:35 am    Post subject: cfg-update doesn't preserve file permissions Reply with quote

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
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Thu Mar 13, 2008 7:54 pm    Post subject: Reply with quote

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
View user's profile Send private message
heini
n00b
n00b


Joined: 20 Sep 2002
Posts: 32

PostPosted: Fri Mar 14, 2008 10:42 am    Post subject: Reply with quote

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.

Quote:
cfg-update -udv

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
View user's profile Send private message
heini
n00b
n00b


Joined: 20 Sep 2002
Posts: 32

PostPosted: Fri Mar 14, 2008 10:59 am    Post subject: Reply with quote

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
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Sun Mar 16, 2008 10:50 am    Post subject: Reply with quote

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
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Mon Mar 31, 2008 3:13 am    Post subject: Reply with quote

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 :P
[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
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Mon Mar 31, 2008 10:04 pm    Post subject: Reply with quote

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
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Tue Apr 01, 2008 12:46 am    Post subject: Reply with quote

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
View user's profile Send private message
XenoTerraCide
Veteran
Veteran


Joined: 18 Jan 2004
Posts: 1418
Location: MI, USA

PostPosted: Sun Apr 13, 2008 12:37 am    Post subject: Reply with quote

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
View user's profile Send private message
xentric
Guru
Guru


Joined: 16 Mar 2003
Posts: 410
Location: Netherlands

PostPosted: Fri Jul 11, 2008 7:30 pm    Post subject: Reply with quote

******************************************************************************

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
View user's profile Send private message
Uzytkownik
Guru
Guru


Joined: 31 Oct 2004
Posts: 391
Location: Munich, DE

PostPosted: Mon Sep 20, 2010 12:39 pm    Post subject: Reply with quote

Bug still present in 2010.
_________________
I've probably left my head... somwhere. Please wait untill I find it.
Back to top
View user's profile Send private message
rich0
Developer
Developer


Joined: 15 Sep 2002
Posts: 109

PostPosted: Sun Oct 02, 2011 11:00 am    Post subject: Taking over maintenance Reply with quote

FYI - I'll be taking over maintenance of this package in portage.
Back to top
View user's profile Send private message
Uzytkownik
Guru
Guru


Joined: 31 Oct 2004
Posts: 391
Location: Munich, DE

PostPosted: Sun Oct 02, 2011 8:35 pm    Post subject: Re: Taking over maintenance Reply with quote

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
View user's profile Send private message
rich0
Developer
Developer


Joined: 15 Sep 2002
Posts: 109

PostPosted: Sun Oct 02, 2011 8:42 pm    Post subject: Re: Taking over maintenance Reply with quote

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
View user's profile Send private message
Uzytkownik
Guru
Guru


Joined: 31 Oct 2004
Posts: 391
Location: Munich, DE

PostPosted: Sun Oct 02, 2011 8:48 pm    Post subject: Re: Taking over maintenance Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3
Page 3 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum