/etc/hosts and /etc/inet/hosts

we're running Sol10x86 11-06 and notice that there's no link between /etc/hosts and /etc/inet/hosts as there has been on some previous versions. /etc/hosts is the only file that contains all of the info for our IPMP configuration, and that seems to be enough during reboot.
what looks at /etc/inet/hosts? any danger in making /etc/inet/hosts a link to /etc/hosts?

I don't have a copy of 11/06, but I've never seen a default installation of Solaris without that link.
It's certainly there in 08/07. Is there any chance that whatever process is populating /etc/hosts on your machines is breaking that link?
Darren

Similar Messages

  • /etc/group and /etc/passwd corrupted

    My /etc/group and /etc/passwd (and possibly others) are corrupted (my silly error handling pacnew files). I tried restoring the backups (group- and similar) and also ran grpconv, pwdconv,, pwck without fixing things.  I've edited the files, using those in another machine as a template but no luck.
    Various commands (e.g. ssh) fail with the message:
                                     No user exists for uid 1000
    Before I give up and reinstall, is there any way I can restore things to how they should be?

    Thanks for replies. I can't recreate my user because it's already there. I can log in as ac without difficulty and do most things - just a few (mportant) fail.
    I don't understand why it keeps saying the user ac is uid 1000. After reading the wikis I think my /etc/group and /etc/passwd are correct. /etc/passwd has:
                ac:x:1000:100::/home/ac:/bin/bash
    and /etc/group has:
               users:x:100:ac
               ac:x:100:ac
    I'm not sure the last line should be there, but removing it doesn't help. The entries on a second machine are similar.
    I'll sleep on it to see if I think of something else to try in the morning, otherwise I'll have to reinstall tomorrow.

  • [SOLVED] Today's update of /etc/group, /etc/passwd and /etc/gshadow

    Hello,
    During the regular updates I received an update of /etc/groups. I wonder what I should do here, as there are some differences between the old file and the pacnew one. I suppose that when I use the command to add my user to a group, it gets written into this file. So, just recklessly moving the pacnew file in the place of the old one, will mess up all my groups, won't it?
    Then what should I do? All the entries in the pacnew file are also present in the old one, so I guess I could just delete the pacnew one and keep the old one. Am I right?
    EDIT: The same goes to /etc/passwd and /etc/gshadow.
    Last edited by Unia (2012-10-06 09:51:23)

    teateawhy wrote:
    If you had the uuid user before like me the uuid line in your own files is different from the pacnew file. You have to delete the uuid line near the bottom in your old file. Then insert the new uuid entry including the new number in the place near the top suggested by the pacnew file. Keep the other lines untouched, then save your changes and delete the pacnew files.
    Edit: On a system that has actually been modified from a default install the new files will for sure be different to the old ones.
    Thanks, teateawhy!  I currently have this listed in /etc/passwd:
    uuidd:x:998:998::/:/sbin/nologin
    And this is in the .pacnew file:
    uuidd:x:68:68:uuidd:/:/sbin/nologin
    So, I can just copy the entry from the .pacnew file, overwriting the old entry, right?
    What I don't understand is how the two numbers 998 representing the UID and GID can suddenly change to 68.  Shouldn't they have to correspond with some other reference or list of users/groups...?
    I'm sure it's fine to just replace the entry as you suggested, but I wondered if there was a way to double-check which uid/gid should be used?  It's not that I don't trust you, but I don't fully understand how these group/passwd files work and I'm trying to get my head round it all.
    Cheers,
    esuhl

  • Login Process & Security of /etc/passwd and /etc/shadow

    Guys,
    I have few questions, Please help me out.
    1. What is the Solaris 8 and Solaris 9 environment's boot files ?
    2. While Logging into Solaris Operating Environment , which is file is responsible for Login Process ? Through which file/command the username and password is cross checked with /etc/passwd and /etc/shadow ?
    3. We all know that /etc/passwd come with -rw-r--r-- permission and /etc/shadow comes with -r--------. I did a chmod and assigned 000 to both the files. But Still I am able to change the password for the normal user. And as a root I am still able to cat the contents of both the files.
    Help me understand these concepts.
    Thank you.
    Arut

    Sounds like you're very new to Solaris:
    1. What is the Solaris 8 and Solaris 9 environment's boot files ?/kernel/genunix is the primary boot file. The directory structure in /kernel is also boot related. /usr/kernel is also boot related.
    2. While Logging into Solaris Operating Environment , which is file is responsible for Login Process ? Through which file/command the username and password is cross checked with /etc/passwd and /etc/shadow ?Generally three files are related: /etc/passwd, /etc/shadow, and the program /bin/login. Some applications will process /etc/passwd and /etc/shadow on their own and bypass /bin/login - but for you're purposes this is a good general answer.
    As a minor example (and if I remember correctly), say someone uses telnet to log into a system. Telnet prompts for the login ID. Once input, it passes forks off /bin/login with the login ID. /bin/login reads the user password information from /etc/shadow and takes the first two bytes from the password field (column 2 using : as field seperator) which is the crypt salt (see crypt man page). /bin/login prompts for the password which the user inputs. /bin/login takes the user input password and the salt value read from /etc/shadow for that user and pushes it through crypt. It then takes the resultant crypt output and compares it against what it read from /etc/shadow - if they matches the user has input the right password. If not, it prompts the user again with a password prompt.
    3. We all know that /etc/passwd come with -rw-r--r-- permission and /etc/shadow comes with -r--------. I did a chmod and assigned 000 to both the files. But Still I am able to change the password for the normal user. And as a root I am still able to cat the contents of both the files.To change your password you run the passwd command. That command is SUID root - so for a short period of time you become root within the context of that process. Root is basically god mode and doesn't care about file access priviledges generally. So that fact that /etc/passwd and /etc/shadow have 000 file access permissions doesn't matter - root can still read and write to them.

  • How to recover /etc/passwd and /etc/shadow files

    hi
    Unfortunetly I have a big problem is that someone crash the /etc/passwd and /etc/shadow files from my running server, and my all users are not to able to login. so please can any one help me how to recover this files or any ideas for make these files...
    thanks
    Mohammed Tanvir

    Hello
    It is not working.Pla help me this bit critical
    Step followed
    01.Boot from the cdrom and mount root partision.
    02.Deleted the exsisting file /etc/passwd and /etc/shadow
    03.copy the opasswd and oshadow to the etc directory as passwd and shadow
    04.Umount the root partision
    05.Reeboot the system
    thanks
    Roshantha

  • [SOLVED] /etc/passwd and /etc/shadow -- pwck shows missing groups

    I recently found out about the pwck and grpck commands to check for errors/inconsistencies in the passwd, group, shadow and gshadow files...  grpck returns no errors, but pwck returns this:
    user 'avahi': no group 84
    user 'postgres': no group 88
    user 'ntp': no group 87
    pwck: no changes
    These are the relevant lines from /etc/passwd:
    avahi:x:84:84:Avahi daemon:/:/bin/false
    postgres:x:88:88:PostgreSQL user:/var/lib/postgres:/bin/bash
    ntp:x:87:87:Network Time Protocol:/var/lib/ntp:/bin/false
    There are lines for those users in /etc/shadow... but...  I'm not sure what I need to do to fix the problem.
    I think I understand enough, now, to maintain the files in future, but would anyone know I can fix this?
    Last edited by esuhl (2012-10-08 20:22:05)

    2ManyDogs wrote:I don't know how to fix the errors, but I'm really curious about why you decided to run those commands. Were you having a problem you thought might be ralated to groups and/or passwords? What are groups 84, 97, and 88?
    Ha!  Well... when I started using Arch I really didn't know much about Linux and I an update providing some .pacnew files (/etc/group, gshadow, passwd, shadow) and... well...  I don't know what I did, but I think it was probably not what I should have done(!).  I used grpck in the past and got no errors and it suddenly occurred to me today that there should be an equivalent for checking /etc/passwd... so that's why I just ran the commands now.  Everything seems to be working, however...
    I don't have an entry for groups 84, 87 and 88 in my /etc/group file...  Hmmm...
    I tried running this command to find any files associated with that group, but only get the following:
    [root@i7pc tim]# find / -gid 88
    find: `/run/user/1000/gvfs': Permission denied
    find: `/proc/1806/task/1806/fd/5': No such file or directory
    find: `/proc/1806/task/1806/fdinfo/5': No such file or directory
    find: `/proc/1806/fd/5': No such file or directory
    find: `/proc/1806/fdinfo/5': No such file or directory
    I get similar output for the other groups, so... can I just delete them from /etc/passwd and /etc/shadow?
    I notice I have the avahi package installed, however, and group 84 relates to user 'avahi'... so...  surely I need the avahi user...?
    Last edited by esuhl (2012-10-07 23:09:30)

  • [Solved] Questions about /etc/group and /etc/gshadow

    This morning, package filesystem was upgraded to 2015.02-1 and pacnew files were created for /etc/group and /etc/gshadow. I ran diff against my current files, and the differences seem very minor, to me. I need some guidance to understand whether I should implement the pacnew changes.
    The only significant difference I see in the group file is that in my original version, my username is added to the wheel group. This seems correct, to me.
    For gshadow, there is the same difference for wheel. However, there are several entries where my original entry contains an exclamation point, but the new version does not. For example:
    < proc:!::
    > proc:::
    If I run man /etc/gshadow, it does not give me what I understand as a man page, and gives me what appears to be a listing of the stuff in my /etc/gshadow file, instead. Which does not help me.
    So, like I say, I need some guidance on dealing with these pacnew files.
    Tim
    PS - I now see that "man gshadow" gives me an actual man page. Sorry. I am currently studying it.
    Last edited by ratcheer (2015-02-24 21:37:52)

    After the update to filesystem 2015.02-1 some voices in /etc/gshadow were changed (in the pacnew file) from
    systemd-journal-gateway:!::
    systemd-timesync:!::
    systemd-network:!::
    systemd-bus-proxy:!::
    systemd-resolve:!::
    to
    systemd-journal-gateway:::
    systemd-timesync:::
    systemd-network:::
    systemd-bus-proxy:::
    systemd-resolve:::
    What's the change? Before they had a locked password (the ! sign) and now they haven't?

  • Socket functions and /etc/hosts and /etc/servi​ces

    I have verified that I con open a socket with either the host name or the IP address.
    But can I use either the port number or the service name (from /etc/services)?
    It allows me to use a string constant instead of a numeric, but it doesn't seem to work.

    The string form for the port number is specifically meant to use the NI Service Locator service and nothing else. It does not link into /etc/services or anything like that at all but is a proprietary service locator solution from NI. There exist LabVIEW VIs that one can use to both query this service as well as register new services. It can be found at vi.lib/Utility/ServLocInterface.llb. The actual service used to be programmed in LabVIEW around LabVIEW 7.0 but quickly was moved to a real system service at least on Windows. Not sure if other platforms still use the VI based service implementation or have a native service deamon too, for this.
    Theoretically it would be possible to create some translation program in LabVIEW that reads /etc/services and then registers them through the service locator API but I'm not sure I see a real benefit in this.
    Rolf Kalbermatter
    CIT Engineering Netherlands
    a division of Test & Measurement Solutions

  • Deleted my /etc/groups and /etc/gshadow and now no mouse and keyboard.

    Hey.
    So a few days ago I updated my system and did something we all know to avoid. I accidently moved the empty .pacnew files over my groups and gshadow files so my entire group layout is out of the window. I am an idiot I know. My mom told me that when I was six. So I am now looking at fixing my system. My biggest problem is that now xorg runs but the keyboard and mouse don't respownd. This isn't a USB problem since I tried using non USB keyboard. In runlevel 3 keyboard works fine.
    Xorg.log says something about input bring used by someone else  so my guess based on the above is that what I need to do is restore my old groups since its probably a group ownership problem. My question is if anyone knows which groups should I restore and how does one go about repairing the Damage? I would be thankfully to anyone who would take the time saving me from my own stupidity.
    Last edited by Greenstuff (2012-08-22 08:03:26)

    This might be the solution. Perhaps I should post my /etc/group file and you can fix yours? I don't know, did you ensure that all your groups have the correct GID?

  • Migration form /etc/passwd and /etc/shadow to iPlanet Directory !

    Hi,
    we try to migrate from files (shadow passwd on Solaris) to LDAP- Server from iPlanet. So far so good. Our problem is now to migrate users, which have no password (NP in shadow) or users with an locked account (*LK* in shadow). Is there an attribute or flag, e.g. in the class shadowaccout which describes this issue.

    Hi Alois,
    I assume that your question is about preventing locked or no-password users from logging into the directory.
    The easiest would be to inactivate both no-password and locked users. I would
    1) create one role for both no-password and locked users, then
    2) assign the corresponding role to each user who is either locked or has no password
    3) inactivate both roles.
    By inactivating a role, all users possessing that particular role become inactivated. Inactivated users can not login to the directory.
    I would recommend you to read the 'Advanced Entry Management' chapter of the administrator's guide.
    I hope this helps.
    Bertold

  • /etc/auto_home and Lion

    Hi there,
    at work we support Mac clients autheticating against a RedHat Directory Server. Network users get their home
    directories from the LDAP automout maps.
    In  them Mac client, running OS X prior to Lion (leopard and snow leopard) I am able to accomplish it by editing: Login Options provide a network Accout server (my Linux LDAP server) and then from the System prederence GUI navigate to Login Options network account server and set 'RFC 2307' for LDAP Mappings.
    When propted for Base Suffix I specify:
    o=beo.al.gov,dc=beo,dc=al,dc=gov.
    The above allows me to authenticate MAC users. They are able to find an automounted home in the MAC when the /etc/auto_master, /etc/auto_home
    and /etc/autofs.conf look like this:
    % cat /etc/auto_master
             # Automounter master map
             +auto_master            # Use directory service
             /net                    -hosts
             -nobrowse,resvport,nosuid
             /home                   auto_home       -nobrowse,resvport
             /Network/Servers        -fstab
             /-                      -static
    % cat /etc/autofs.conf
      [snip]
               # Mount options.
               # A string containing a comma-separated list of mount
               # options
               # that will be applied, by default, to all mounts done by
               # automountd(8).
               # The options for a particular mount can override these
               # options.
               # This controls the same default mount options that the
               # -o option to
               # automountd(8) controls.
               AUTOMOUNTD_MNTOPTS=nosuid,nodev,resvport
               [snip]
    and
    % cat /etc/auto_home
              # Automounter map for /home
              +auto_home      # Use directory service
               In Mac clients running Lion 10.7.3 I tried the above changes but my users don't find their home when they login.  In addition to the modification of /et
    c/autofs.conf and /etc/auto_master in order for my user to see their home directories I have also to add a complete list of all the mount points in the mac-lion's: /et
    c/auto_home like this:
             # Automounter map for /home
             +auto_home      # Use directory service
             [snip]
             db25_hera_public
             hera:/export/db25/hera_public
             db25_user_office
             hera:/export/db25/user_office
             Public                          odysseynfs:/Public
             Public2                         odysseynfs:/Public2
             ajax                           users.xr:/export/ajax
             zeus
             zeus.as4.al.gov:/export/zeus
             zeus4
             zeus.as4.al.gov:/export/zeus4
             ogmgr                          ulisses:/ogmgr
             achilles
             achillesnfs48:/export/achilles
             .etc...
             [snip]
    It appears thus that the automounter behaves differently in Lion  compared to snow-leopard or ealier versions of the Mac OS X.  How do I make it behave more  like snow-leopard so that I don' have to carry around the above /etc/auto_home large file when I upgrade my mac clients? 
    thanks in advance for your help!   __ giampiero

    Hi Felbit,
    I searched in the discussions about /etc/auto_home and Lion but came out empty
    A friend opened a call with Apple about this same issue but got no reply...
    I think that we are on the 'bleading-edge' here.
    I though that my solution would help
    i.e.
    1) Login Options:  specify Your  Network Account server (I have a Linux LDAP server) from the System preference GUI
    then: navigate to Login Options network account server and set 'RFC 2307' for LDAP Mappings.
    When prompted for Base Suffix I specify:
    o=beo.al.gov,dc=beo,dc=al,dc=gov.
    2) edit /etc/auto_master to read:
             # Automounter master map
             +auto_master            # Use directory service
             /net                    -hosts
             -nobrowse,resvport,nosuid
             /home                   auto_home       -nobrowse,resvport
             /Network/Servers        -fstab
             /-                      -static
      and /etc/
    autofs.conf
      [snip]
               # Mount options.
               # A string containing a comma-separated list of mount
               # options
               # that will be applied, by default, to all mounts done by
               # automountd(8).
               # The options for a particular mount can override these
               # options.
               # This controls the same default mount options that the
               # -o option to
               # automountd(8) controls.
               AUTOMOUNTD_MNTOPTS=nosuid,nodev,resvport
               [snip]
    3) append all the mounts you need in your /etc/auto_home file:
    like this:
             # Automounter map for /home
             +auto_home      # Use directory service
             db25_hera_public
             hera:/export/db25/hera_public
             db25_user_office
             hera:/export/db25/user_office
             Public                          odysseynfs:/Public
             Public2                         odysseynfs:/Public2
             ajax                           users.xr:/export/ajax
    (...) etc..
    is the above not working from you?
    It should work for Lion and it works also on leopard and snow leopard as well.
    Is step 3  giving you problems?
    Did you also try mounting manually your filesystem like this:
    sudo mount achillesnfs48:/export/achilles /mnt

  • [SOLVED] /etc/group or /etc/gshadow are inconsistent, grpck shows " ".

    After updating, pacman said
    ==> Warning: /etc/group or /etc/gshadow are inconsistent.
    but when running grpck there was no output.
    I would guess this means everything is OK. Is this the case?
    In case it matters, these are my /etc/group and /etc/gshadow.
    Last edited by trusktr (2013-09-06 07:46:30)

    Check these:
    https://bbs.archlinux.org/viewtopic.php?id=131484
    https://bbs.archlinux.org/viewtopic.php?pid=1064456

  • Network-profiles (1) and /etc/hosts

    Hi everyone,
    i've got a few network-profiles, especially in one network I have to use a static ip to connect to the internet. The only entry in the /etc/hosts which works correctly - without any error messages - for me, is
    192.168.0.99 localhost.localdomain myhost
    If I use something like 127.0.0.1 in front and simply add my hostname at the end, I can't connect with the Inet, unfortunately. I did not test it, but I'm pretty sure, that this host configuration won't work in any other network, where I get a dynamic IP from the DHCP. Is there a possibility to write the content of the /etc/hosts with netcfg, like the /etc/resolv.conf for example?
    MfG Skit

    Because you didn't specify what localhost was in your hosts file. It only knows of localhost.localdomain(does not imply 'localhost') and acer being the loopback.
    I think he understood that.
    'localhost' is universally understood as the loopback.
    this is some kind of 'magic' answer isn't it? the resolving doesn't come out as a miracle... and that is IMHO what needs explanation.
    his computer alone doesn't (obviously) get it because sure, it's not set. now what 'magic' makes it known when a cable is plugged in? the computer tries to reslove locally (via /etc/hosts), fails at it, and then asks the dns server about it. so I reckon the dns server is instructed on replying '127.0.0.1' for a 'localhost' hostname request. why so? because dns servers have an option to look at their local /etc/host for resolving before delegating to bigger servers, so the dns server certainly has localhost matching 127.0.0.1 in his /etc/host, and blindly replies accordingly, oblivious to the fact that he is replying about his 'own' 127.0.0.1 to someone else.
    Last edited by lloeki (2008-01-16 08:24:12)

  • Oracle 11gR2 RAC VM and SCAN and DNS and /etc/hosts (two) setup questions

    Hi,
    I am looking forward to setting up two Oracle 11gR2 RAC instances
    on my Oracle VM test machine.
    I plan on using the Oracle 11gR2 RAC VM template.
    I want the final Oracle 11gR2 RAC instances to have SCAN that uses DNS.
    The DNS will be pre-installed in the JeOS.
    My first simple question about the setup is the following.
    In my DNS name file, for example,
    /var/named/chroot/var/named/milkyway.univ.db
    do I need to provide the racnode1 and racnode2 information,
    for example,
    # DNS name file (snippet)
    myjeos IN A 192.168.1.150
    racnode1 IN A 192.168.1.161
    racnode1-vip IN A 192.168.1.163
    racnode2 IN A 192.168.1.162
    racnode2-vip IN A 192.168.1.164
    rac-scan IN A 192.168.1.131
    rac-scan IN A 192.168.1.132
    rac-scan IN A 192.168.1.133
    Or, can I just provide only the rac-scan information
    # DNS name file alternate (snippet)
    myjeos IN A 192.168.1.150
    rac-scan IN A 192.168.1.131
    rac-scan IN A 192.168.1.132
    rac-scan IN A 192.168.1.133
    What I am getting at is the following.
    Within the install process, will racnode1, racnode1-vip, racnode2,
    and racnode2-vip host names and their IP address be written
    to the RAC instances /etc/hosts files? (So I should not bother
    to put them in the DNS name file like '# DNS name file alternate (snippet)'?)
    Or, should I put the racnode and racnode-vip host names and IP addresses
    in the DNS name file like '# DNS name file (snippet)'?
    The second question is the following.
    Are the cluster name and the scan name allowed to be different?
    Currently, I would plan them to be different,
    for example, rac-cluster and rac-scan.
    Or, are they required to be the same,
    for example, rac-cluster and rac-cluster.
    Thank you.
    AIM

    AIM wrote:
    do I need to provide the racnode1 and racnode2 information,
    Or, can I just provide only the rac-scan information You need to provide all of it in DNS, because other hosts in your network will need to be able to resolve all of the normal, VIP and SCAN addresses for your RAC nodes. We write this data out to /etc/hosts just to reduce the amount of round-trip DNS requests the cluster nodes make for themselves.
    Are the cluster name and the scan name allowed to be different?They can be different.

  • Sshd ignores /etc/hosts.allow and /etc/hosts.deny

    Hello everyone,
    I've just found out that sshd ignores /etc/hosts.allow and /etc/hosts.deny completely on my machine. It doesn't make use of tcp_wrappers. I am using the standard Arch package. Either my settings are wrong, or this is a severe security problem. It was a terrible surprise to find out that my server is under severe dictionary attacks all the time, despite the denyhosts script I am using.
    These are my settings:
    /etc/hosts.deny:
    ALL: ALL
    /etc/hosts.allow:
    # some nfs daemons: 192.168.1.0/255.255.255.0
    sshd sshd1 sshd2: ALL EXCEPT /etc/hosts.evil
    mysqld: 192.168.1.0/255.255.255.0
    /etc/hosts.evil:
    195.113.21.131
    60.10.6.53
    A simple experiment to verify the settings:
    [root@charon etc]# tcpdmatch -d -i /etc/xinetd.conf sshd 195.113.21.131
    warning: sshd: no such process name in /etc/xinetd.conf
    client: address 195.113.21.131
    server: process sshd
    matched: hosts.deny line 5
    access: denied
    [root@charon etc]# tcpdmatch -d -i /etc/xinetd.conf sshd 195.113.21.130
    warning: sshd: no such process name in /etc/xinetd.conf
    client: address 195.113.21.130
    server: process sshd
    matched: hosts.allow line 10
    access: granted
    This seems to be fine. But when I go to the machine 195.113.21.131, I can simply log in with no trouble at all.
    This is really strange. Does it have something to do with the xinetd warning? I am not using xinetd... Maybe I'm doing something wrong. If you have experienced such a trouble, please give me a hint.

    elasticdog wrote:So should our package not have the ListenAddress 0.0.0.0 line uncommented by default?  My guess would be that since it listens on all local addresses by default, we're just overwriting that when specifying 0.0.0.0, which isn't valid.  That was users don't have to specify their local IP address.  Unless I'm wrong, shouldn't this be a bug/feature request for the packager?
    This doesn't seem to be a package bug... IMHO, sshd must respect all the settings in hosts.deny and hosts.allow, regardless the IP address it listens on. The behaviour I noticed seems to be much more complicated. Basic settings (daemon name mentioned in hosts.*) worked, as far as I didn't want a "per IP" configuration. For example, including the daemon in hosts.allow really enabled remote connections, but any closer specifications (subdomains, EXCEPT operator...) were ignored. Access was simply granted without further evaluation. Excluding sshd from hosts.allow worked as one would assume. When I specified ListenAddress, everything started to work properly. This is mysterious. There are millions of computers using tcp wrappers and ssh, so it's hard to believe there could be a bug.

Maybe you are looking for