# mailbase-0.00-r8 breaks things again.

## Antek Grzymala

Hi,

I just upgraded to mailbase-0.00-r8 (having to remove /etc/pam.d/{imap,pop}), and again got into problems with running programs that access /var/spool/mail/<whatever> directly.

Can't the devs agree on a sensible set of permissions for mailbase and make other programs adhere to it? I'm using (and I'm not alone) mutt and evolution, and they both break with the new mailbase perms:

mutt: "Folder readonly" -> (Recompliing mutt fixes that)

evolution: "Could not lock folder /var/spool/whatever..." -> (Still got to see whether recompiling evolution will fix this)

There should be some loud einfo in the ebuild telling people what to do after upgrading to this version (like rebuilding your mutt), and I consider the lack of it a major s*up.

Apart from that -- thanks to the devs for all the great work.

Antoni

Update: Recompiling evolution helped as far as I'm concerned. Don't know about any other mail clients, as I'm not using them.

----------

## j-m

Ehmm....

https://bugs.gentoo.org/show_bug.cgi?id=74622

And, basically, 1777 or 0777 is insecure, see https://bugs.gentoo.org/show_bug.cgi?id=16749 for reasons.

----------

## Antek Grzymala

 *Quote:*   

> Ehmm....
> 
> https://bugs.gentoo.org/show_bug.cgi?id=74622

 

This is about -r6 (and I've already been through the -r5 -r6 mess), guess something could have been done, at least warning users.

[a]

----------

## j-m

 *Antek Grzymala wrote:*   

> 
> 
> This is about -r6 (and I've already been through the -r5 -r6 mess), guess something could have been done, at least warning users.
> 
> 

 

No, this is not about -r6, this is the explanation of your problems and applies to -r8 likewise. Please post you comments and suggestions there, it won´t help at all if you rant here.

----------

## Dave_Lindquist

OK, this is the first time I've come away without any helpful advice from searching the forums  :Wink: 

I've read the bugs mentioned, and they don't seem to have any helpful advice, just a lot of commentary that I'm not following very well...

I'm stuck with a mailbase update I can't emerge because it collides with qpopper on /etc/pam.d/pop3.

So, one of the following must be true:

1) mailbase is broken

2) qpopper is broken

3) I'm an idiot for having both mailbase and qpopper installed

Can someone explain what the issues are?

It seems to me that qpopper (being the one that does the authentication) is the logical candidate to hold the pam.d file.... Which then begs the question of why mailbase is suddenly trying to do it?

Anyone have any solutions yet?

----------

## j-m

 *Dave_Lindquist wrote:*   

> OK, this is the first time I've come away without any helpful advice from searching the forums 
> 
> I've read the bugs mentioned, and they don't seem to have any helpful advice, just a lot of commentary that I'm not following very well...
> 
> I'm stuck with a mailbase update I can't emerge because it collides with qpopper on /etc/pam.d/pop3.
> ...

 

OMG. Can´t you read plain English instructions provided by the ebuild?  :Rolling Eyes: 

- move the colliding files somewhere else

- emerge mailbase

- if needed, put your customizations back to those files now emerged by mailbase

- done

This all is written plain and clear in the error message. I don´t understand what is your problem.  :Question:   :Shocked: 

----------

## stolen

The problem is, why do we have multiple packages supplying the same files, when we need those packages to be installed at the same time?

----------

## j-m

 *stolen wrote:*   

> The problem is, why do we have multiple packages supplying the same files, when we need those packages to be installed at the same time?

 

The whole purpose of mailbase´s existence is to remove the behaviour you have just discribed...  :Exclamation:   :Idea: 

----------

## Dave_Lindquist

 *j-m wrote:*   

> OMG. Can´t you read plain English instructions provided by the ebuild? 
> 
> - move the colliding files somewhere else
> 
> - emerge mailbase
> ...

 

...and then if I need to rebuild qpopper for some reason, boom, there goes the mailbase version of the file....

The point is not that I *could* do this, the point is that this isn't a solution.

From your last post, it sounds like the intention is to migrate this file *out* of qpopper (or whatever other package provides it), and *into* mailbase, and only half the job is done?

After all the whole point of ebuilds is to remove the manual labor necessary to install, upgrade, and maintain things  :Wink: 

(I apologize for the nerve I seem to have stepped on...  :Wink:  )

----------

## j-m

 *Dave_Lindquist wrote:*   

> 
> 
> ...and then if I need to rebuild qpopper for some reason, boom, there goes the mailbase version of the file....
> 
> 

 

Try the latest unstable version of qpopper. If you have this problem with that one, file a bug for qpopper. Mailbase aims to emerge files common to all MTA packages itself and remove that files from all other MTA ebuilds. I really can´t see why it this so hard to understand. The only problem is that you have to do the transition - this horrible trouble consists of following the instructions and moving one or two files somewhere else. Duh!  :Rolling Eyes: 

```

# ChangeLog for net-mail/qpopper

# Copyright 2000-2005 Gentoo Foundation; Distributed under the GPL v2

# $Header: /var/cvsroot/gentoo-x86/net-mail/qpopper/ChangeLog,v 1.19 2005/02/14 13:49:32 plasmaroo Exp $

  14 Feb 2005; <plasmaroo@gentoo.org> qpopper-4.0.5-r1.ebuild,

  qpopper-4.0.5-r2.ebuild:

  Add sys-libs/db DEPEND if we're not using gdbm.

*qpopper-4.0.5-r2 (13 Feb 2005)

  13 Feb 2005; Fernando J. Pereda <ferdy@gentoo.org>

  +qpopper-4.0.5-r2.ebuild:

  Remove pam.d stuff and make it depend on at least mailbase-0.00-r8 (#79240)

```

----------

## ]DL[JimmyJazz

 *j-m wrote:*   

> OMG. Can´t you read plain English instructions provided by the ebuild? 
> 
> - move the colliding files somewhere else
> 
> - emerge mailbase
> ...

 

I can read plain English, but I don't see a damned word about why this collision exists.

```
>>> emerge (1 of 1) net-mail/mailbase-0.00-r8 to /

 * Checking for possible file collisions...

 * //etc/pam.d/pop3 exists and wasn't provided by mailbase

 * //etc/pam.d/imap exists and wasn't provided by mailbase

 * Those files listed above have to be removed in order to

 *  install this version of mailbase.

 * If you edited them, remember to backup and when restoring make

 *  sure the first line in each file is:

 * # Provided by mailbase (dont remove this line!)

!!! ERROR: net-mail/mailbase-0.00-r8 failed.

!!! Function pkg_setup, Line 50, Exitcode 0

!!! Can't be installed, files will collide

!!! If you need support, post the topmost build error, NOT this status message.

Messages from build:

 === 2005-03-04 17:13 ==== mailbase-0.00-r8 ===

 * Checking for possible file collisions...

 * //etc/pam.d/pop3 exists and wasn't provided by mailbase

 * //etc/pam.d/imap exists and wasn't provided by mailbase

 * Those files listed above have to be removed in order to

 *  install this version of mailbase.

 * If you edited them, remember to backup and when restoring make

 *  sure the first line in each file is:

 * # Provided by mailbase (dont remove this line!)

!!! ERROR: net-mail/mailbase-0.00-r8 failed.

!!! Function pkg_setup, Line 50, Exitcode 0

!!! Can't be installed, files will collide

!!! If you need support, post the topmost build error, NOT this status message.

(These messages can be seen in /tmp/emerge-watched.log)

```

The problem, my nearsighted friend, is that in world of real production servers, sysadmins are not button-pushing monkeys, but are actually responsible for the health of the systems under their care.  Real sysadmins need to know the why as well as the what in the ebuild info.  We can't be satisfied with watching our feet, but need to see a ways down the road, as well.  The job's half-baked? Not good enough. Unstable versions on production servers?  Not in this lifetime.  As much as I like Gentoo for the most part, it's crap like this that prevents it from being taken seriously in the corporate world.  And it's self-righteous buttheads like yourself that keep Linux from becoming more mainstream than it should be.  Try to see the world from eyes that aren't nose-deep in MTA lore, buddy.

----------

## Carlo

 *]DL[JimmyJazz wrote:*   

> The problem, my nearsighted friend, is that in world of real production servers, sysadmins are not button-pushing monkeys, but are actually responsible for the health of the systems under their care.  Real sysadmins need to know the why as well as the what in the ebuild info.  We can't be satisfied with watching our feet, but need to see a ways down the road, as well.  The job's half-baked? Not good enough. Unstable versions on production servers?  Not in this lifetime.  As much as I like Gentoo for the most part, it's crap like this that prevents it from being taken seriously in the corporate world.  And it's self-righteous buttheads like yourself that keep Linux from becoming more mainstream than it should be.  Try to see the world from eyes that aren't nose-deep in MTA lore, buddy.

 

It shows indeed that Gentoo isn't as matured as e.g. Debian. If you consider the growth rate of Gentoo and the amount of work compared to the number of developers, it'd maybe a good idea to ask yourself what you can do - hey, it's still a community distro - to improve the situation, instead ranting.

 :Arrow:  Staffing Needs

----------

## j-m

 *]DL[JimmyJazz wrote:*   

>  *j-m wrote:*   OMG. Can´t you read plain English instructions provided by the ebuild? 
> 
> - move the colliding files somewhere else
> 
> - emerge mailbase
> ...

 

This collision exists b/c two or more packages provide the same files. You need to apply common sense, that´s enough. If it does not help, then sorry. The mailbase ebuild was made exactly to get rid of this, duh!  :Rolling Eyes: 

The only "problem" is that you have to do the transition at some point of time, what on earth is so difficult to understand? That you need move the damned two plaintext files out of the way? If you are unable to do this, then find someone who can. Also if you would be so kind and did search the bugzilla, you would find the answers there.

----------

## Buzz

 *j-m wrote:*   

> 
> 
> OMG. Can´t you read plain English instructions provided by the ebuild? 
> 
> 

 

 *j-m wrote:*   

> 
> 
> This collision exists b/c two or more packages provide the same files. You need to apply common sense, that´s enough. If it does not help, then sorry. The mailbase ebuild was made exactly to get rid of this, duh! 
> 
> The only "problem" is that you have to do the transition at some point of time, what on earth is so difficult to understand? That you need move the damned two plaintext files out of the way? If you are unable to do this, then find someone who can. Also if you would be so kind and did search the bugzilla, you would find the answers there.

 

This kind of arrogant, condescending language is totally unnecessary and baffles me as to the motive you have in using it.  This is the first forum I encounter about this problem, and while your posts seem to be helpful, it looks like a requirement for getting the help is to be subjected to "It is so ridiculously, insanely, obvious!! Try to overcome your inferior intellect and spontaneously 'know' what you came here to find out." Duh!  :Rolling Eyes:   Everybody has different backgrounds and levels of competency with regards to different packages, what they do, and how doing different things within the gentoo system affect their lives.

For what it's worth, it is much clearer to me what is going on after sifting through your above posts...

Thanks for your answers,

Buzz

----------

## j-m

I´ve been trying to explain several times what is mailbase and what to do with this issue. After all of this, the comment comes:

 *Quote:*   

> 
> 
> Real sysadmins need to know the why as well as the what in the ebuild info. We can't be satisfied with watching our feet, but need to see a ways down the road, as well. The job's half-baked? Not good enough.
> 
> 

 

Sorry, you won´t get the "why" sort of information in RPMs, you won´t get them in DEBs, you won´t get them in TGZs. You have changelogs, you have forums, documentation, you have http://gentoo-portage.com/, you have bugzilla... So please don´t complain "why oh why I don´t get any information about that evil mailbase package which broke my Gentoo". It´s really just a pathetic attempt.

----------

## mciann

j-m -

I am also one of the people who are trying to actually use the system for something other than watching glxgears.  We can read the error and understand how to blindly resolve it, if that is what we want to do.  Those of us responsible for maintaining these systems have a few pertinent questions before we go moving files around and restoring them.

If we move the files away, emerge -u mailbase, then move them back, we will obviously arrive at a final configuration other than what was intended by mailbase.  The contents of certain VERY important files will be changed from the configuration that mailbase intends.  The location of symlinks will be different.  Permissions will be different.  Bugs referenced in this very thread indicate that this has caused problems with mail clients in the past.  It is not very difficult to see how a disruption of permissions and/or files can result in the disruption of an e-mail system which transacts thousands of messages per day via postfix and courier-imap.  I can either move the files, let mailbase do what it wants, and let my mail system get screwed up because I've pissed off courier-imap, postfix, maildrop, and God knows what else, or I can copy the files back afterward, and get my mail system screwed up because I've pissed off mailbase.  These options are not acceptable.  We need to understand exactly why these file collisions are taking place so that we can resolve them intelligently for our systems.

Why does mailbase want to overwrite these files?  If someone has built a mail system that does something slightly more complicated than the occaisonal script-generated sendmail command, what is the best way to make sure critically important system functions such as imap pam authentication (!) still work after all these file moving gymnastics?

The WHY is the critical question here, and that question has been addressed by exactly no one so far.

----------

## Carlo

 *mciann wrote:*   

> The WHY is the critical question here, and that question has been addressed by exactly no one so far.

 

 :Arrow:  Bug 79240

----------

## mciann

Okay, in summary (and because I hate googling threads that end in RTFM), the problem is that the intended final configuration is that mailbase should provide the /etc/pam.d files, and that courier-imap should depend upon mailbase to do so.  The courier-imap package, as of this time, inappropriately provides the same files and should be changed so that it uses the files provided by mailbase.  Therefore, users of courier-imap should await a new release of courier-imap which fixes this problem.  Until then, updates should be emerged indvidually.  Mailbase should NOT be emerged until a compliant version of courier-imap becomes available.

Thanks.

----------

## riksta

 *mciann wrote:*   

> Okay, in summary (and because I hate googling threads that end in RTFM), the problem is that the intended final configuration is that mailbase should provide the /etc/pam.d files, and that courier-imap should depend upon mailbase to do so.  The courier-imap package, as of this time, inappropriately provides the same files and should be changed so that it uses the files provided by mailbase.  Therefore, users of courier-imap should await a new release of courier-imap which fixes this problem.  Until then, updates should be emerged indvidually.  Mailbase should NOT be emerged until a compliant version of courier-imap becomes available.

 

Rubbish! just do as portage asks, and move the files out, then replace them, making sure the 1st line is as stated, I followed this procedure, and it works perfectly

----------

## mciann

Wow, OK, so TFM wasn't quite enough to sort this out.  Thanks for pitching in, riksta.

----------

## riksta

 *mciann wrote:*   

> Thanks for pitching in, riksta.

 

Pleasure, hope you are sorted out?

----------

## autarkeia

If you search for other posts by j-m you'll see he has a you-are-an-idiot-for-not-undertsanding-what-I-understand tone in nearly all of his posts, and when people call him on it he continues to act like they are stupid and that their questions have immediately obvious answers, basically belittling them for asking a question in the first place. I really don't understand why someone needs to be a jerk when attempting to help other people (and I do mean attempting, because most of his posts are insults rather than help). Maybe I will make it a pet project to find posts by j-m and belittle all of his questions.

"j-m can't you read/write English? Why are you even asking this question? Why are you even using Linux? You should be using Microsoft products and then calling their tech supportand dealing with spyware and viruses and leave this code stuff to the real nerds. Why don't you read the ebuild files? Screw ebu ilds, why don't you drill down and read the source code? Who cares if Portage isn't working how it's supposed to, you should figure it out and not ask any questions, and if you do I will belittle you even more! Okay, you're just an idiot, let's face it. In fact, life is looking pretty bleak for you, why don't you just end it?"

j-m take a clue from people and inject some measured maturity into your responses. Some people just do not have your knowledge, and likewise you do not have theirs. Share yours without being pedantic and everyone will be better off for it.

----------

## Carlo

 *autarkeia wrote:*   

> If you search for other posts by j-m you'll see he has a you-are-an-idiot-for-not-undertsanding-what-I-understand tone in nearly all of his posts

 

Could you please just ignore him, if you think so? Picking on each other doesn't resolve problems and your tone isn't the one I'm used to read here either.

----------

## Earthwings

Calm down everyone, please.

----------

## mciann

Rubbish! just do as portage asks, and move the files out, then replace them, making sure the 1st line is as stated, I followed this procedure, and it works perfectly

Hi, there, just a little follow up.  I just recently got around to emerging the new packages following the procedure you described, and now none of my users can get their e-mail.

Thanks.

----------

## phrozen77

 *Quote:*   

> and now none of my users can get their e-mail.
> 
> 

 

similar problem here... after doing a emerge -u world, portage borking on mailbase and then moving the mentioned files in /etc/pam.d/ somewhere else, im no longer able to login into horde... (Login failed for some reason. Most likely your username or password was entered incorrectly. (login _is_ ok, also tried with a freshly added user...))

no matter if i use the "original" files, which are btw somewhat similar besides the comments, the results are the same...

i also already changed the permissions to those 2 + another, seemingly updated file, to 744 as the others are in /etc/pam.d/

when trying to send an email to a (previously?) existing user it bounces with 

```
Technical details of permanent failure: 

PERM_FAILURE: SMTP Error (state 10): 553 sorry, that domain isn't in my list of allowed rcpthosts (#5.7.1)
```

 but it is..

it also says 

```
This is an automatically generated Delivery Status Notification

Delivery to the following recipient failed permanently:

     username@url.com
```

 which sorta suggests it isnt there anymore... still all of this also fails with a new added user, as stated above...

any ideas && help is greatly appreciated and if you need more details, just let me know

regards

<edit> 

got it working again, found some errors in /var/log/messages which in the end lead me to https://forums.gentoo.org/viewtopic.php?t=283741

 *Quote:*   

> # cp /etc/courier-imap/authdaemonrc /etc/courier/authlib/authdaemonrc
> 
> # /etc/init.d/courier-authlib restart 

 

did it (and removing old and no longer needed init-scripts for authdaemon)

</edit>

----------

## risa2000

What I see right now as the biggest problem with current setup is that it breaks "emerge -e world" regulary. Even though "emerge -e world" is something probably I do not do on regular basis, right now I am switching compiler and so I am there.

Unfortunately, it is quite a annoyance when after few hours of compilation it bails out saying me that there are some files which collide with the new ones and I need to manually handle this. Why it cannot be handled like normal etc-update stuff, so the package will install new files alongside and then emerge will report the discrepancy at the end?

And since I am also (yet happy) user of courier-imap, I wonder what I am going to face after the rebuild is finished.  :Confused: 

----------

## DaleCooper82

Hi everyone.

I am a little bit confused by the status of this (mailbase, pam) and must admit scared to emerge mailbase (which is now required by emerge -uDav world) on our main mail server. 

What I understand is that I should:

a) backup /etc/pam.d/pop3 and /etc/pam.d/imap

b) emerge mailbase-r8

c) get back backed up files from (a)

d) keep the comment left by mailbase on the first line in these files (something like "# generated by mailbase...")

Now, if you (I) search the forums, some people claim it works, for some it does not... and I would like to do this in one nice and clean try as I do not intend to spend the weekend at work trying to fix this. Could anyone who went through this confirm that above mentioned steps would work, please?

Thanks,

Dale

Our setup is:

* postfix

* courrier-imap

* cyrus-sasl

----------

## coulon

I'm also in the same predicament as DaleCooper82, with the very same mail setup; has anyone come up with a definitive solution? I also noticed the fact that there doesn't seem to be consistent success with the backup->emerge mailbase->copy back approach, and I'd really like to avoid taking down the mail system here, especially if it's in a manner that's easily traceable to me. Anyone have luck with this (and anyone have any idea when this problem will be ironed out in portage?)

----------

