As stated in the title: What does the #... in the output below mean? I don't think they are hostnames, because I think the #-sign is reserved for mailing. Normally there stands a IP-subnet or simply an IP-address - but nothing is the case here. I also know I can put hostnames in there, but I don't think I could put such #... into the hosts file to restrict the access to only some IPs... Sooo, what is this?
glaforge#enterprise: showmount -e [REMOVED]
Export list for [REMOVED]:
[REMOVED] *
[REMOVED] #somenamea,#somenameb
In the list of exports shown by showmount -e any names with an # are netgroups, not individual hosts.
A netgroup is a list of hosts. They're typically defined in /etc/netgroup on the NFS server (but could also be in NIS, LDAP, etc. depending on how /etc/nsswitch.conf is configured).
Using netgroups to define your exports saves a lot of typing compared to exporting to each host separately. (I find that it reduces the chances of making typos. Or if I do make a typo in one of my exports, I'll find it faster as it'll affect all the machines in the netgroup rather than just one machine.)
Example
On my NFS server I could have the following netgroups defined in /net/netgroup:
nuts (walnut,,) (almond,,) (pistachio,,) (hazelnut,,)
flowers (rose,,) (tulip,,) (iris,,)
Each entry in a netgroup is defined as a tuple of (hostname, user, NIS domain) but NFS only cares about the hostname so just leave the other parts blank. The NIS domain is not the same thing as a DNS domain. If you need to specify a full DNS name, e.g., foo.example.com, put it all in the host part: (foo.example.com,,)
And then my exports file could look like this:
/vol/home #nuts(rw) #flowers(rw)
/vol/web #nuts(rw)
/vol/dns #nuts(ro) almond(rw)
Now the hosts in the flowers netgroup can mount home read-write but can't access web or dns. The host almond has read-write access to everything, but the rest of the machines in the nuts netgroup only have read-only access to dns.
If I were to run showmount -e it would look something like this:
% showmount -e
Export list for example.com:
/vol/home #nuts,#flowers
/vol/web #nuts
/vol/dns #nuts,almond
Related
I have a bunch of directories [ "mydir", "mydir1", "mydir2" , "mydir3" ]. This list will grow eventually.
How can i set the ownership of directories "mydir*" ?. Will the wildcard * can be used in puppet resource.I am aware of the looping through the array of directories and setting up the permission. Since this list is growing i want to use some wildcard like "mydir*".
The short answer is no, Puppet does not support wildcard resource names. There is a good explanation with workarounds at https://ask.puppet.com/question/15769/can-we-use-wild-cards-in-file-resource-path-and-source-parameters/.
The longer answer is no, Puppet does not support wildcard resource names, because the resources are typically enumerated on the Puppet server, which doesn't have access to the client filesystems and so can't run a wildcard to generate matches. As the Puppet answer above says, one option is to use an exec resource to set the ownership using a shell glob, something like
exec { 'Change owner and group to user.group on /bar/foo*':
path => '/bin',
command => 'chown user.group /bar/foo*',
}
Note that the use exec resources has problems of its own. In this particularly example, the resource is not idempotent, so will run every time Puppet agent runs, which is not generally acceptable.
I have a unix command 'abc' which gives me an output
This abc lies on my server.
But when i run this command from server, i want to restrict the output of it to be seen by people.
By the above statement , i meant..
For eg. If i say:
ls dirname
I can see the output of the above command on the console.
So, if the command is run from command-line, i dont want to have echoed on the console. I cant use /dev/null as I am using the same command from my program where I need the output to be assigned to a variable and then use it further in my application.
However, I want to get the output of this command when I call this from my program.
How can I differentiate the call in this regard.
The command whoami gives you the current logged user, and the command last -i outputs information of the last logged users in the system, including the IP address (3rd column) and the timestamp or a string stating that the user is stil logged in.
With that in mind you could pipe these commands:
last -i | grep $(whoami) | grep 'still logged in'
which will provide an output like this:
(username) pts/2 0.0.0.0 Wed Dec 23 18:58 still logged in
(username) :0 0.0.0.0 Wed Dec 23 11:13 still logged in
so if you are running a shell in the same host, the IP will be 0.0.0.0 and different otherwise. You can extract the IP string by piping awk at the end of the command.
However, addhering to the philosophy in unix systems of Do One Thing and Do It Well, I'd suggest a different approach, split your command into 2 different commands:
A command to be used by the clients, where the output is whatever you
want the clients to see
Another command (offering 2 options, since there isnt much detail in the question):
Either extending the first command, adding the additional output, and using this one from your application
Or just generating the additional output, and using a combination of the 2 commands from your application
Some of the benefits you can get by following this approach:
Performing checks to verify where the command was issued from, is no longer necessary
Avoid coupling issues
Easier to maintain
Updated: added the means to extract the IP of the current user at the beggining of the answer.
You were a little vague on the complete setup, so I'll have to infer a few things. Since you mentioned, "my" server, I assume you can set permissions on files, change ownership on files, etc (e.g. you can become root).
I also have to infer that the target abc program just produces some output and doesn't need to modify any files to speak of [other than (e.g.) /tmp/temp.$$]
As an example, let's do this from your home directory. Move the program abc to $HOME/private_bin and set the directory permission to 700 which means that only you can execute it.
Create a second directory: $HOME/public_bin that has normal permissions. Create a "launcher" program [let's call it abcpub] and put it in this directory. Set the permissions of abcpub to 4741. It's now a setuid program. Note that any non-root user may do this for files they own. It is not like creating a sudo because an ordinary user would need to do chown root ...
Now we're set ...
You can access the real abc program anytime you want. Others have no direct access to abc.
The launcher abcpub will allow others to have access to abc, but the launcher can apply whatever restrictions you desire: including no access, output to /dev/null, etc. abcpub can look at getuid and geteuid to determine who is executing it [you or somebody else]
We did the above example using your own uid and home directory. But, we can repeat the process by creating an "abc" user in /etc/passwd and a /home/abc. The abc user could be set up with a shell of /sbin/nologin. Thus, it's similar to nobody and it can't hurt anything.
It may be even better doing this by creating a setgrp program instead of setuid as that allows better comingling. The original user could retain their user permissions but still get access via the new group.
Also, it may be possible to configure sudo to get what you want.
On Ubuntu 12.04 I am tring to get the subtree of management values with the following command:
snmpwalk -v 2c -c public localhost
with the last line of the output being
iso.3.6.1.2.1.25.1.7.0 = No more variables left in this MIB View (It is past the end of the MIB tree)
Is this an error? A warning? Does the subtree end there?
There's a bit more going on here than you might suspect. I encounter this on every new Ubuntu box that I build, and I do consider it a problem (not an error, but a problem--more on this down further).
Here's the technically-correct explanation (why this is not an "error"):
"No more variables left in this MIB View" is not particularly an error; rather, it is a statement about your request. The request started at something simple, say ".1.3" and continued to ask for the "next" lexicographic OID. It got "next" OIDs until that last one, at which point the agent has informed you that there's nothing more to see; don't bother asking.
Now, here's why I consider it a problem (in the context of this question):
The point of installing "snmpd" and running it is to gather meaningful information about the box; typically, this information is performance-oriented. For example, the three general things that I need to know about are network-interface information (IF-MIB::ifHCInOctets and IF-MIB::ifHCOutOctets), disk information (UCD-SNMP-MIB::dskUsed and UCD-SNMP-MIB::dskTotal), and CPU information (UCD-SNMP-MIB::ssCpuRawIdle, UCD-SNMP-MIB::ssCpuRawWait, and so on).
The default Ubuntu "snmpd" configuration specifically denies just about everything useful with this configuration (limiting access to just enough information to tell you that the box is a Linux box):
view systemonly included .1.3.6.1.2.1.1
view systemonly included .1.3.6.1.2.1.25.1
rocommunity public default -V systemonly
This configuration locks the box down, which may be "safe" if it will be on an insecure network with little SNMP administration knowledge available.
However, the first thing that I do is remove the "-V systemonly" portion of the "rocommunity" setting; this will allow all available SNMP information to be accessed (read-only) via the community string of "public".
If you do that, then you'll probably see what you're expecting, which is pages and pages of SNMP information that you can use to gauge the performance of your box.
I know this thread is probably very old the I fix this is to use:
rocommunity public
and that should fix the problem.
Briefly, this is not an error, actually, when you "walk up" all OIDs on your agent, it will shows your this line>
Sometimes, it won't show you this line, because the last OID is not on your agent(you have already walk up all OIDs on your agent, but not walk up all OIDs).
$ snmpwalk -v 2c -c public localhost NET-SNMP-EXTEND-MIB::nsExtendObjects
NET-SNMP-EXTEND-MIB::nsExtendObjects = No more variables left in this MIB View (It is past the end of the MIB tree)
Also you can get this error while you can trying to see executed scripts I fix that problem to add
view all included .1 80
line to snmpd.conf than restart service
Than you will see your output going to change for both input
we have a script that needs to take action on a finite list of hosts. but every time we add or remove a host to the /etc/hosts file, we end up having to update this script.
basically, say my hosts file looks like:
192.168.100.1 hostip_1
192.168.100.2 hostip_2
192.168.100.10 hostip_3
192.168.100.20 hostip_5
and my script (bash) does something like:
callmyfunction hostip_1
callmyfunction hostip_2
callmyfunction hostip_3
callmyfunction hostip_5
if i want to add hostip_4 to the list of hosts, i now have to go in and edit my script and add it to the list. while it's a small edit, it is still a step that can be forgotten in the process (especially if someone new to the system comes in).
is there a way i can test to see if 'hostip_1' is a valid hostname within the system (without pinging the host or grepping the /etc/hosts file)? we may use multiple hosts files, and different configurations may have different filenames, so i can't rely on trying to grep a single file. i need the system to do that work for me.
any clues?
first, my statement about things not being in the hosts file is wrong. that is exactly where they are. dumb on my part.
but the answer is:
getent hosts
that will get it to print everything out, and i can do a lookup from there.
As you are populating the /etc/hosts file, I am assuming that you are not using DNS. So below solution wont fit your use case. But it will still get you some pointers.
In a working DNS environment, you can check the host name to its corresponding IP with below command
# host host_name
This is will give the IP address of the host. In case the host name does not exists, then it will give you corresponding host not found message.
You can parse the output of above command and can deduce whether a give host name exists.
might not be in your /etc/hosts file... better search for the name and see if an ip can be found:
(($(dig +noall +answer google.de |wc -c)>0)) && echo exists
this is bash, can be adaptet to pretty much everything.
dig +noall +answer google.de
returns the ips if found. If empty, that name cannot be used in the computer running this code.
If all the targets are on the same subnet (same network), use arping, it will check that hosts are available using ARP.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about a specific programming problem, a software algorithm, or software tools primarily used by programmers. If you believe the question would be on-topic on another Stack Exchange site, you can leave a comment to explain where the question may be able to be answered.
Closed 1 year ago.
Improve this question
I've just performed a new installation of the very latest (Fall, 2008) version of Fedora 9 Linux and am perplexed that it never set the default route properly and that even traveling the labyrinthine ways of this OS, there's no obvious way.
Of course, it's clear that one can do it on a one-off basis like this:
route add default gw gw1 metric 0 eth0
or like this:
ip route add to default via 192.168.2.1 protocol static
However, neither of these survives reboot. In reading through /etc/rc.d/init.d/network, it attempts to find data from a file in /etc/sysconfig/static-routes, but that file never existed. So, I tried to create it and populate it with data. The trouble with that is that the script places a dash (minus sign) in an odd spot that I'm not sure how to deal with.
Of course, one can just edit /etc/rc.d/init.d/network, but that would be non-standard. As it is, my only other recourse seems to be editing rc.local, but that doesn't come early enough in the boot sequence to be there for things like, for example, the network time daemon.
I've done my homework - I've read all the man pages, info entries, tried apropos, and I've even done a fair bit of web searching, all to no avail - my next step, sans answer here, will be to sign up to the Fedora mailing lists and ask there! Or, give up and edit the scripts.
So, how is one supposed to do this?
The gateway is normally set in /etc/sysconfig/network-scripts/ifcfg-eth0, not in /etc/sysconfig/network. For example, on my current machine:
/etc/sysconfig/network
NETWORKING=yes
NETWORKING_IPV6=no
HOSTNAME=flyboys
NISDOMAIN=ekcineon
/etc/sysconfig/network-scripts/ifcfg-eth0
DEVICE=eth0
ONBOOT=yes
HWADDR=00:1d:09:31:3a:cc
NETMASK=255.255.255.0
IPADDR=150.102.65.30
GATEWAY=150.102.65.252
TYPE=Ethernet
Note that I set HWADDR because I have two ethernet cards and I want to make sure the right one is assigned to eth0. The configuration for the second card is in /etc/sysconfig/network-scripts/ifcfg-eth1
just edit the /etc/sysconfig/network-scripts/route-ethXX
and write inside: default via ip_address dev device , replace ip_address with your gateway ip and device with the name of the right eth device. but for the Device option its ... optional, set it in the case of multiple eth devices.
Works even in case of network restart, the route directive in rc.local works at boot only.
I have not used recent versions of Fedora, but it was often set as a GATEWAY variable in /etc/sysconfig/network.
Of course, if you just wanted it to work, you could just put the commands in /etc/rc.local to be executed when the boot sequence completes.
You can use nmcli if available, e.i.
# nmcli con show
NAME UUID TYPE DEVICE
System eth0 xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet eth0
ens33 xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ethernet --
# nmcli con edit "System eth0"
nmcli> goto ipv4
You may edit the following properties: method, dns, dns-search, dns-options, dns-priority, addresses, gateway, routes, route-metric, route-table, routing-rules, ignore-auto-routes, ignore-auto-dns, dhcp-client-id, dhcp-timeout, dhcp-send-hostname, dhcp-hostname, dhcp-fqdn, never-default, may-fail, dad-timeout
nmcli ipv4>
nmcli ipv4> print
['ipv4' setting values]
ipv4.method: manual
ipv4.dns: --
ipv4.dns-search: --
ipv4.dns-options: --
ipv4.dns-priority: 0
ipv4.addresses: 10.10.10.1/26
ipv4.gateway: 10.10.10.129
ipv4.routes: --
ipv4.route-metric: -1
ipv4.route-table: 0 (unspec)
ipv4.routing-rules: --
ipv4.ignore-auto-routes: no
ipv4.ignore-auto-dns: no
ipv4.dhcp-client-id: --
ipv4.dhcp-timeout: 0 (default)
ipv4.dhcp-send-hostname: yes
ipv4.dhcp-hostname: --
ipv4.dhcp-fqdn: --
ipv4.never-default: no
ipv4.may-fail: yes
ipv4.dad-timeout: -1 (default)
nmcli ipv4>
nmcli ipv4> set routes 192.168.122.0/24 10.10.10.1
nmcli ipv4> verify
Verify setting 'ipv4': OK
nmcli ipv4> save
nmcli ipv4> quit
#nmcli con up "System eth0"
And it should create file /etc/sysconfig/network-scripts/routes- with proper parameters, e.g.
ADDRESS0=192.0.2.0
NETMASK0=255.255.255.0
GATEWAY0=198.51.100.1
Haven't seen Fedora. But shouldn't there be some GUI for this kind of thing? If you have Gnome try running gnome-network-preferences
Here it is for RHEL, as it is slightly different:
Identify the interface by using ifconfig
sudo vi /etc/sysconfig/network-scripts/route-ethXX
add the routes as per syntax below, where /xx represents subnet mask
host: 172.30.xxx.xxx via 172.30.xxx.xxx
network: 172.30.xxx.xxx/xx via 172.30.xxx.xxx
Default gateway: 0.0.0.0 via xxx.xxx.xxx.xxx</li>
Save the file.
sudo /etc/init.d/network restart (Warning: if you forget to set
correct routes for the management interface (if applicable) you may lose
connectivity to the server)