# New Baselayout has no domainname, breaks NIS/YP [SOLVED]

## sirlark

Hi,

I recently updated to baselayout-1.12.4-r7, ran etc-update, and my /etc/init.d/domainname disappeared. This means that a) I have no domainname on reboot anymore, and b) NIS/YP's ypbind won't start cause NISDOMAINNAME isn't set. I've been on #gentoo, and been told that the disappearance is not unique to me, but that it doesn;t seem to break the other guys system. Of course not that many people seem to run ypbind these days...

I have done some digging and found that despite the disappearance of the domainname script other initscripts (most specifically ypbind) refer to it, usually in the form of a need/use/depend statement

I can only imagine that this is an oversite, or I've completely missed that there's a new way of initialising the system's domainnames that I don't know about.

*edit* it turns out that I completely missed that there's a new way of initialising the system's domainnames that I didn't know about. look at /etc/conf.d/net.example, or more specificaly setting dns_domain and nis_domain. *edit*

At the moment, by users cannot log onto any of their machines without me logging in as root on their machines and manually setting the domainnames and restarting ypbind

ANY and ALL help appreciated, I'm getting really desparate,

thanks

----------

## nephros

Not sure how your system set up the NIS domain previously, but if you were using /etc/nisdomain or similar you should configure both DNS and NIS domains in /etc/conf.d/domainname now.

----------

## sirlark

NISDOMAINNAME and DOMAINNAME are set in /etc/conf.d/domainname, and were originally refereneced and set up when the domainname initscript ran, i.e. the script run when "rc-update add domainname boot" turns it on == /etc/init.d/domainname, which is now no longer there, yet the config file remains, curious... seems like it just got left out by mistake

----------

## BT

I have also noticed that the domainname init script has disappeared. However the domainname conf.d file is still present. I doubt it's an oversite as the instructions for configuring a domain name have been removed from the installation documentation.Last edited by BT on Fri Sep 08, 2006 2:14 am; edited 1 time in total

----------

## sirlark

Oversight or not, I guess my ultimate question remains: how in the new baselayout system do I set my domainname during boot, so that nisdomainname is set correctly BEFORE ypbind tres to start

----------

## iom

you have to set it in /etc/conf.d/net instead:

```

config_eth0=( "1xx.x.6x.123 netmask 255.255.255.0" )

routes_eth0=("default gw 1xx.x.6x.1")

dns_domain_eth0="xxx.xxx.xx"

dns_servers_eth0="q.q.q.q w.w.w.w"

dns_search_eth0="domain1.qq domain2.qq"

nis_domain_eth0="OurNisDomain"

nis_servers_eth0="q.w.e.r r.e.w.q q.r.t.w"

```

----------

## sirlark

Right got it, yet another case of the notifiction was buried in a whole pile of flying compile lines... whoops

Anyway, one further question remains, the dns_servers_ethX, does that replace resolv.conf?

----------

## nephros

 *sirlark wrote:*   

> Right got it, yet another case of the notifiction was buried in a whole pile of flying compile lines... whoops
> 
> Anyway, one further question remains, the dns_servers_ethX, does that replace resolv.conf?

 

This, if I read the comments correctly, it set up in /etc/conf.d/domainname through the OVERRIDE variable.

----------

## sirlark

/etc/conf.d/domainname is no longer processed in the init scripts as far asI can tell, whch is whereall my problems came in in the first place, the OVERIDE setting was to determine whether conf.d/domainname settings could be overridden by dhcpcd iirc

----------

## UberLord

 *sirlark wrote:*   

> Anyway, one further question remains, the dns_servers_ethX, does that replace resolv.conf?

 

Yes.

If you need a finer grain of control, install and configure resolvconf-gentoo

----------

## sirlark

How does that interact with gethostbyname calls? Or does the net initscript modify the contents of /etc/resolv.conf when it's run...

----------

## UberLord

 *sirlark wrote:*   

> How does that interact with gethostbyname calls?

 

It doesn't

However, it does store each resolv.conf generated by each interface and then provide a single resolv.conf based on that.

 *Quote:*   

> Or does the net initscript modify the contents of /etc/resolv.conf when it's run...

 

It does indeed.

Unless resolvconf-gentoo is installed.

----------

## overshoot

 *UberLord wrote:*   

> When baselayout tells you to update config files or things break WE REALLY DO MEAN IT

 

All well and good if baselayout is the last thing emerged.

In future, I suppose I should hand-emerge each package individually to make sure that I don't miss any messages, since they don't get logged in /var/log/emerge.log

Of course, that does sort of negate some of the goodness of portage, no?

----------

## UberLord

 *overshoot wrote:*   

>  *UberLord wrote:*   When baselayout tells you to update config files or things break WE REALLY DO MEAN IT 
> 
> All well and good if baselayout is the last thing emerged.
> 
> In future, I suppose I should hand-emerge each package individually to make sure that I don't miss any messages, since they don't get logged in /var/log/emerge.log
> ...

 

Then look into a tool such as elog.

----------

## sirlark

elog?

Can't find it in portage, no man page for it, which elog can't find it, locate can't find it, and google shows up a blogging app.

----------

## UberLord

Or just take note of the fact that when an emerge finishes, portage kindly tells you that you have x number of config files that need updating.

Maybe we should patch it to put a big bright warning in place saying

"IT'S A VERY GOOD IDEA TO ADDRESS THIS!"

----------

## sirlark

actually, how difficult would it be to just have ewarn and the other functions duplicate their output to a tempory file, the path of which is set by emerge in the form of an environment variable based on the pid of the emerge process, and then at the end of the process, emerge spits out the contents o fhte temp file and deletes it..

ebuild could also set it's own environment var which is prepended to each line produced by ewarn and friends, containing the category/package of the package producing the message.

----------

## UberLord

Been done.

Checkout /etc/make.conf.example - for ELOG settings. Assuming it's been recently etc-updated that is   :Rolling Eyes: 

----------

## sirlark

In reference to the patch for big white warning messages about adressing outdated config files, I have to ask

why is there developer resistance to adressing the issue of warnings and other things flying by. This has been an issue of contention for some time now, and certainly something I've wanted adressed since portage 1.x. I don't believe that there's any real difficulty to the programming, but rather there seems to be an almost idelogical resistance to making warning message appear in a more useful manner.

All in all, even making the post-emerge config update warning more visible won't help the issue much. The baselayout issue a perfect example...

I DID run etc-update, and everything broke! It broke because etc-update did not (and reasonably should not, to be fair) transfer my /etc/conf.d/domainname settings to the new system. The message that told me where how and why I had to enter my settings into the new system flew past, and no amount of post emerge warnings would have helped.

"When baselayout tells you to update config files or things break WE REALLY DO MEAN IT" is not reasonable response. Good advice yes, but a blanket "stop being a noob about this" sort of reply, that isn't always appropriate... except when someone's being a noob  :Wink: 

----------

## sirlark

WHOA NELLY! Sorry bout that last post, a bit quick off the mark there... I was writing it as you're last post came through Uberlord... apologies..

----------

## sirlark

That having been said, How do I configure PORTAGE_ELOG_.* to produce the behaviour I want, namely, to collect all warnings, errors, and notifications as they are produced, save them, and have emerge automatically spit them when it exits?

----------

## UberLord

Ask one of the portage guys in #gentoo-portage on irc.freenode.org - I don't actually use it myself  :Wink: 

----------

## ferdog

I have this in my /etc/make.conf:

```
PORTAGE_ELOG_CLASSES="info warn error log"

PORTAGE_ELOG_SYSTEM="save"
```

That does the job for me.

----------

## overshoot

 *iom wrote:*   

> you have to set it in /etc/conf.d/net instead:
> 
> ```
> 
> config_eth0=( "1xx.x.6x.123 netmask 255.255.255.0" )
> ...

 

As with most things NIS-related, it doesn't work.

```
nis_domain_eth0="foo"

nis_servers_eth0="nis_root"
```

results in

```
$ domainname -y

example.com
```

(Mozilla insists on doing the reverse, and the Moz developers insist that setting the default mail domain to "foo" is correct.  If $COMPANY didn't insist on using NIS, I'd drown it -- nobody loves the fool thing.)

nis-domain is actually set by the dhcp derver, but the dhcp clients don't process it.

----------

## jhill10110

Unbelievable. I love Gentoo and have been using it since 1.2 but I think this may be the  final example of why this distro can't be run in production. I *really* like portage and the speed of development but at the same time I can't have my system being turned upside down once a month with massive system configuration changes. 

Can't we have package updates without making a new OS every time? How about if major changes are kept for the point releases and then provide documentation on changes BEFORE they fly by the screen in an update that has already occured on the system. 

Increasing logging does not help. If the change has already been made it is too late for me, I need to know before it is applied to my system.

I've heard people say before that they love Gentoo but don't have the time for it and I think I am now starting to agree with them. I think the only way to run Gentoo in a production environment is to have identical test systems in place to build packages and test changes / dependancies, etc. In all but the smallest environments this is difficult at best. 

I'm honestly not sure what other choices I have, maybe Ubuntu Server or FreeBSD. I may not be happy with those either but at least at this point I am officially looking for a new "home".   :Sad: 

P.S. Maybe the new Server/Desktop branches could be the answer. I do not like pointing out problems without offering solutions but I'm really not sure of what the best way to fix this is.

----------

## converter

 *jhill10110 wrote:*   

> Unbelievable. I love Gentoo and have been using it since 1.2 but I think this may be the  final example of why this distro can't be run in production. I *really* like portage and the speed of development but at the same time I can't have my system being turned upside down once a month with massive system configuration changes.

 

Gentoo needs a formal mechanism for delivery of upcoming feature change advisories. It would be terrific if the portage system could be expanded to serve as the transport for these advisories and point users at them when they arrive. A short paragraph advising users that major changes will be included in a package that will be released in x days would be enough to give users the information they'd need to quickly resolve breakages. If I know that control of configuration of name resolution is going to move from point A to point B when baselayout version n is released and all hell breaks loose when that package is merged, I'll know exactly where to go to fix things. Even one or two days' notice would be better than the current situation.

----------

## pholthau

I believe that this would be a great idea. Adding one or two sentences to emerge -v when a major change of configuration etc. occurs.

----------

## b-o-s-s

 *overshoot wrote:*   

> 
> 
> As with most things NIS-related, it doesn't work.
> 
> 

 

LOL. This simple statement pretty much sums up my own experience with NIS in the last years...  :Very Happy: 

But seriously, I think you need to have a look at /etc/conf.d/domainname. This overrides the setting in /etc/conf.d/net and the default NISDOMAIN entry reads example.com. This "new" way is very confusing...

For me it works. The only annoyance I see is that the machine now needs very long to boot. After starting portmap it just hangs for 1-2 mins. Anyone got an idea what this could be?

Thanks.

----------

## converter

 *b-o-s-s wrote:*   

> 
> 
> For me it works. The only annoyance I see is that the machine now needs very long to boot. After starting portmap it just hangs for 1-2 mins. Anyone got an idea what this could be?
> 
> 

 

Sounds like something is timing out. Is there anything in the logs that gives clues about the problem? I'd be inclined to figure out how to get a tcpdump session started up as early in the boot process as practical, looking for packets from port mapper. Try to figure out what it's trying to do and why it's failing.

----------

## sirlark

A couple of things

Actually the /etc/conf.d/domainname isn't checked/run/used at all in the new config. At least If I grep /etc/init.d for domainname, nothing comes up... Once I set up things correctly in /etc/conf.d/net, NIS works perfectly for me.

As far as the discussion as to using portage as a transport mechanism for announcements re up and coming major configuration changes, firstly I think it souldn't require -v, nor should it warn of things coming up in x days... Using -v means some people would miss it, and warning of things coming up in X days, means those people who only update once every three or four months (and we are out there) would miss the announcements anyway.

I feel it would be better if when emerge was run, after depenecy checking, and before emerges start happening, a large warning message pops up that stays there, i.e. it reuiqres a key press before the emerge continues... Imagine these warning messages would be entered int ortage and downloaded during a sync, and be triggered when certain conditions are met (e.g. updating to a particular version of a particular package as opposed to downgrading or replacing triggers the warning message contained in the ebuild). I'm not sure of the exact mechanics of getting this to work, but I'm sure it can be done...

----------

## dleverton

GLEP 42 should solve the notification problem, although it's not implemented yet.  The idea is to display relevant notices after syncing, but before the upgrade itself.

----------

## b-o-s-s

 *converter wrote:*   

>  *b-o-s-s wrote:*   
> 
> For me it works. The only annoyance I see is that the machine now needs very long to boot. After starting portmap it just hangs for 1-2 mins. Anyone got an idea what this could be?
> 
>  
> ...

 

Thanks for your input, I've found the problem and also a workaround. Have to say it's somewhat unexpected though and not very desireable imo. For anyone interested, I opened a new thread on this:

https://forums.gentoo.org/viewtopic-p-3590867.html#3590867

----------

