I just opened Terminal and I see this m:~ luka$ and not the default that I usually get of "lukasMacBookProEtcEtc:~ luka$
Anyone know why this is? Does this make an impact on what I write into the command line?
Can't find anything on the elsewhere.
This means your computer's host name has changed. This is typical if you switch to a different network, unless you have a statically assigned name or IP address. By default, your computer asks the current network what name to use for itself.
Whether this particular host name is correct or incorrect requires more context. If network operations are working fine for you, then there probably isn't an issue.
No, in general the hostname doesn't directly affect what you write into the command line unless you're writing commands that depend on the current hostname or this unexpected hostname is a symptom of a networking issue and you try entering a command that depends on networking.
Note that on OS X a given computer has at least two different names. One is the “computer name”, typically assigned by the user, and the other is the “host name”, typically assigned to your computer by a server on the local network. The former is the “Computer Name:” at the top of System Preferences > Sharing, and users can usually feel free to name their computers as they wish unless otherwise directed by a system administrator. The host name is visible as the output of the hostname command and is typically displayed in the shell command prompt. You should normally not attempt to change the host name unless directed to by a system administrator.
Related
I need the DNS suffix of all my local interfaces on my PC.
Is there way how I can achieve this via Go?
Best case would be for any OS
Necessary: working on Windows
I have tried net.Inferfaces() and all the net commands but I haven't found anything regarding the DNS server.
EDIT
I have found the solution for the Windows-specific version but it would be interesting if there is anything that works for Linux and macOS too.
I don't think there is a solution that work for any OS. In Linux the DNS suffix is not interface specific but system wide, it is configured in /etc/resolv.conf. Here is an excerpt from the man page:
search Search list for host-name lookup.
By default, the search list contains one entry, the local domain name. It is determined from the local hostname returned by gethostname(2); the local domain name is taken to be everything after the first '.'. Finally, if the hostname does not contain a '.', the root domain is assumed as the
local domain name.
This may be changed by listing the desired domain search path following the search keyword with spaces or tabs separating the names. Resolver queries having fewer than ndots dots (default is 1) in them will be attempted using each component of the search path in turn until a match is found.
For environments with multiple subdomains please read options ndots:n below to avoid man-in-the-middle attacks and unnecessary traffic for the root-dns-servers. Note that this process may be slow and will generate a lot of network traffic if the servers for the listed domains are not local, and
that queries will time out if no server is available for one of the domains.
If there are multiple search directives, only the search list from the last instance is used.
The net package standard library parses this file to get the DNS config, so the DNS resolver should behave as expected, however, the parsing functionality is not exposed.
The libnetwork.GetSearchDomains func in the libnetwork library should be able to help you out. If there are no search entries in /etc/resolv.conf, you should use the hostname, which can be gotten with the os.Hostname func.
I believe this also works for FreeBSD and Mac OS since they are both "UNIX like". But I am not 100% sure.
I am writing a service/module in Go for a bigger system and I'm having trouble with permissions on macOS. I am hoping anyone here has any experience with this.
This module is using network interfaces in macOS (read+write), and therefore needs admin/root permissions. The module is also in the form of a process which will communicate with parent process through stdio. Since it needs root permissions, I have tried wrapping it in AppleScript: do shell script [...] with administrator privileges, but osascripts does not return the output in real time, instead it returns the stdio output when process has exited. I need the stdio output in real-time, and it is annoying to write the password every time the module is started.
So that leaves me with the question of how I can request permissions for network control in Go. Like the popup you see on some programs "wants to use your microphone", only with network permissions. Is this possible?
If not, how can I solve this issue of needing root permission for a real-time module in macOS?
I found a viable solution; launching the script with sudo -S , and asking the user for root password through my own GUI service. As long as the root password isn't stored anywhere, it should be fine security-wise.
What's the difference between:
cat /etc/passwd
and
ypcat passwd
? What is ypcat exactly?
Why do I get this:
ypcat: can't get local yp domain: Local domain name not set
when running
ypcat passwd.
ypcat shows the data from the NIS database, which may not be on your computer. That holds network accounts (which allow you to log into various computers on your network). It is named with a "yp" prefix since the original programs were referred to as "yellow pages" (until Sun and others were told to stop doing that — by the phone company).
cat (of course) shows only data from a file on your computer, which lists local accounts.
Further reading:
28.4. Network Information System (NIS) (FreeBSD handbook)
Using NIS (Introduction to Unix Systems Administration, IFSM 498B)
The cat command is used to concatenate and display the contents of the given files.
ypcat on the other hand
prints out the Network Information Services (NIS) map you specify with the MapName parameter. You can specify either a map name or a map nickname. Because the ypcat command uses the NIS service, you do not need to specify a server
where NIS is
The Network Information Service, or NIS (originally called Yellow Pages or YP) is a client–server directory service protocol for distributing system configuration data such as user and host names between computers on a computer network.
Read about ypcat here : http://www.ibm.com/support/knowledgecenter/ssw_aix_61/com.ibm.aix.cmds6/ypcat.htm
Read about NIS here : https://en.wikipedia.org/wiki/Network_Information_Service
Being fairly new to the Linux environment, and not having local resources to inquire on, I would like to ask what is the preferred method of starting a process at startup as a specific user on a Ubuntu 12.04 system. The reasoning for such a setup is that this machine(s) will be hosting an Input/Output Controller (IOC) in an industrial setting. If the machine fails or restarts, this process must boot automatically..... everytime.
My internet searches have provided two such area's to perform this task:
/etc/rc.local
/etc/init.d/
I ask for the specific advantages and disadvantages of each approach. I'll add that some of these machines are clients and some are servers, but all need to run an IOC, and preferably in the same manner.
Within what ever method above is deemed to be the most appropriate, a bash shell script must be run as my specified user. It is my understanding all start up process are owned by root. So I question if this is the best practice:
sudo -u <user> start_ioc.sh
If this is the case, then I believe it is required to create a file under:
/etc/sudoers.d/
Using:
sudo visudo -f <filename>
Where within this file you assign the appropriate rights and paths to the user. Most of my searches has shown this as the proper format:
<user or group> <host or IP>=(<user or group to run as>)NOPASSWD:<list of comma separated applications>
root ALL=(user)NOPASSWD:/usr/bin/start_ioc.sh
So for final additional information, the ultimate reason for this approach, which may also be flawed logic, is that the IOC process needs to have access to a network attached server (NAS). Allowing root access to the NAS is I believe a no-no, where the user can have the appropriate permissions assigned.
This may not be the best answer, but it is how I decided to complete this task:
Exactly as this post here:
how to run script as another user without password
I did use rc.local to initiate the process at startup. It seems to be working quite well.
I need to gather a list of all mounted "mount points" that the local file system has access to.
This includes:
Any ordinarily mounted volume under /Volumes.
Any NFS volume that's currently mounted under /net.
Any local or remote file system mounted with the "mount" command or auto-mounted somehow.
But I need to avoid accessing any file systems that can be auto-mounted but are currently not mounted. I.e, I do not want to cause any auto-amounting.
My current method is as follows:
Call FSGetVolumeInfo() in a loop to gather all known volumes. This will give me all local drives under /Volumes as well as /net, /home, and NFS mounts under /net.
Call FSGetVolumeParms() to get each volume's "device ID" (this turns out to be the mount path for network volumes).
If the ID is a POSIX path (i.e. it's starting with "/"), I use readdir() on its path's parent to check whether the parent dir contains actually the mount point item (e.g. if ID is /net/MyNetShare, then I readdir /net). If it's not available, I assume this is a auto-mount point with a yet-unmounted volume and therefore exclude it from my list of mounted volumes.
Lastly, if the volume appears mounted, I check if it contains any items. If it does, I add it to my list.
Step 3 is necessary to see whether the path is actually mounted. If I'd instead call lstat() on the full path, it would attempt to automount the file system, which I need to avoid.
Now, even though the above works most of the time, there are still some issues:
The mix of calls to the BSD and Carbon APIs, along with special casing the "device ID" value, is rather unclean.
The FSGetVolumeInfo() call gives me mount points such as "/net" and "/home" even though these do not seem to be actual mount points - the mount points would rather appear inside these. For example, if I'd mount a NFS share at "/net/MyNFSVolume", I'd gather both a "/net" point and a "/net/MyNFSVolume", but the "/net" point is no actual volume.
Worst of all, sometimes the above process still causes active attempts to contact the off-line server, leading to long timeouts.
So, who can show me a better way to find all the actually mounted volumes?
By using the BSD level function getattrlist(), asking for the ATTR_DIR_MOUNTSTATUS attribute, one can test the DIR_MNTSTATUS_TRIGGER flag.
This flag seems to be only set when an automounted share point is currently unreachable. The status of this flag appears to be directly related to the mount status maintained by the automountd daemon that manages re-mounting such mount points: As long as automountd reports that a mount point isn't available, due to the server not responding, the "trigger" flag is set.
Note, however, that this status is not immediately set once a network share becomes inaccessible. Consider this scenario:
The file /etc/auto_master has this line added at the end:
/- auto_mymounts
The file /etc/auto_mymounts has the following content:
/mymounts/MYSERVER1 -nfs,soft,bg,intr,net myserver1:/
This means that there will be a auto-mounting directory at /mymounts/MYSERVER1, giving access to the root of myserver1's exported NFS share.
Let's assume the server is initially reachable. Then we can browse the directory at /mymounts/MYSERVER1, and the DIR_MNTSTATUS_TRIGGER flag will be cleared.
Next, let's make the server become unreachable by simply killing the network connection (such as removing the ethernet cable to turning off Wi-Fi). At this point, when trying to access /mymounts/MYSERVER1 again, we'll get delays and timeouts, and we might even get seemingly valid results such as non-empty directory listings despite the unavailable server. The DIR_MNTSTATUS_TRIGGER flag will remain cleared at this point.
Now put the computer to sleep and wake it up again. At this point, automountd tries to reconnect all auto-mounted volumes again. It will notice that the server is offline and put the mount point into "trigger" state. Now the DIR_MNTSTATUS_TRIGGER flag will be set as desired.
So, while this trigger flag is not the perfect indicator to tell when the remote server is unreachable, it's good enough to tell when the server has become offline for a longer time, as it's usually happening when moving the client computer between different networks, such as between work and home, with the computer being put to sleep in between, thus causing the automountd daemon to detect the reachability of the NFS server.