# How to Change Hostname



## Scribner (Jun 24, 2019)

I recently installed FreeBSD 12.0 and haven't done anything else. I got this message after I booted up, and I suspect it's an error:

`login Jun 23 10:09:27 machine1 ntpd[1109]: error resolving pool 0.freebsd.pool.ntp.org:hostname nor servname provided, or not known (8)`

When I installed FreeBSD, I made the Hostname _machine1.[mydomainwhichisalreadyregistered.com]_. Do you think, because this domain is already registered, this is why I'm getting this message -- even though I was using the machine1 subdomain, which is not set up?

If this is an error, could someone please tell me how to change the Hostname and what it should be. Please also specify if I should be root when I change the Hostname.


----------



## tommiie (Jun 24, 2019)

It looks like your /etc/resolv.conf file is not setup correctly. Do you have internet connectivity, i.e. a valid IP address and default gateway? Can you ping the default gateway and IP addresses on the Internet, e.g. does `ping 8.8.8.8` work?

I remember taking a note on this exact issue after a french install. By default FreeBSD uses a local name server:
	
	



```
nameserver 127.0.0.1
```
 but it doesn't work because of something with DNSSEC. You can either fix that (if I remember how, I'll let you know) or simply change the name server to a differentone, e.g. 
	
	



```
nameserver 8.8.8.8
```

*Edit:* This post explains what needs to be done to fix the DNSSEC issue: https://forums.freebsd.org/threads/useless-system.69357/page-2#post-415452


----------



## Sevendogsbsd (Jun 24, 2019)

Concur with tommie: the error is not that it can't resolve YOUR machine's hostname, but the hostname of an ntp server.


----------



## Scribner (Jun 24, 2019)

Thanks, tommiie.

I logged in and ran `ping 8.8.8.8`, and it seemed to work. However, it never stopped running, and I had to shut down the computer by pushing the power button. Do you think this could have damaged the operating system? In the future, how do I stop a ping from running once it starts?

I just turned the computer on again, and I got the following message:

`Mon Jun 24 10:18:42 CDT 2019

FreeBSD/amd64 (machine1.[mydomainnamethatidontwanttopostpublicly]) (ttyv0)
login:`

Then I logged in and got the following message:

`Edit /etc/motd to change this login announcement.
Need to remove all those ^M characters from a DOS file? Try

     tr -d \\r < dosfile > newfile
          -- Originally by Dru <genesis@istar.ca>
nscribner@machine1:~ %`

Does it look like everything is working as it should now?

Do you think I should still change the Hostname because my domain name is registered, even though the subdomain (machine1) is not set up?


----------



## SirDice (Jun 24, 2019)

Scribner said:


> However, it never stopped running, and I had to shut down the computer by pushing the power button.


CTRL-C, really. It could be worse, my first encounter with vi(1) also resulted in me turning the system off and on again as I couldn't figure out how to exit.



Scribner said:


> Do you think I should still change the Hostname because my domain name is registered, even though the subdomain (machine1) is not set up?


The actual hostname is, for the most part, irrelevant. You typically use the same as the one you use for DNS but the system can actually have a completely different hostname.

Just for information, you can simply change the hostname by editing /etc/rc.conf, change the `hostname=` and restart. That's all you would need to do.


----------



## Sevendogsbsd (Jun 24, 2019)

I am pretty sure the ping goes continuously, but no need to shut the system down, just do a ctrl+c. They may be another key combination to do that but that's what I use. That looks normal to me. When you say "domain name is registered", what do you mean? Is this machine a web server and you have purchased a domain from a company?


----------



## Scribner (Jun 24, 2019)

Sevendogsbsd said:


> I am pretty sure the ping goes continuously, but no need to shut the system down, just do a ctrl+c. They may be another key combination to do that but that's what I use. That looks normal to me. When you say "domain name is registered", what do you mean? Is this machine a web server and you have purchased a domain from a company?


Thanks to SirDice as well.

So it looks like everything should be working the way it should now? I am about to attempt to install Xfce and wanted to make sure everything was normal first.

The domain is registered by me through Google Domains and hosted by pair Networks. The machine is not a Web server.


----------



## tommiie (Jun 24, 2019)

You verified that you have internet connectivity. That's good. Now to fix your original issue: you need to get DNS working so you can resolve domain names to IP addresses. This is done in the file /etc/resolv.conf. See my previous post.

May I suggest you read some books on Linux/Unix for dummies? I mean no offense but since you don't knowthe Ctrl-C combination, nor seem to fully grasp the difference between your own hostname and the DNS resolver, it seems you lack some basic knowledge.


----------



## Scribner (Jun 24, 2019)

No offense taken, tommiie. I understand I'm a noob on these forums, and I appreciate all the help I've gotten so far. I've read Chapters 1-5 in the FreeBSD Handbook, and I also own the book _Absolute FreeBSD, 3rd Edition_. I don't believe there are any current Dummies books on Unix. It's possible they didn't mention the Ctrl-C combination in the Handbook. I did find a forum post on the subject while the ping was going on and the person mentioned Ctrl-C not working, so I didn't even try it (I wish I had).

With that said, do you think I still need to get DNS working, since it doesn't seem I'm getting that message anymore?


----------



## k.jacker (Jun 24, 2019)

Scribner said:


> I did find a forum post on the subject while the ping was going on and the person mentioned Ctrl-C not working


If you mean this thread I recommend reading post #3 of it, where I explain for noobs, how job control works in a shell. Follow the few examples and you‘ll see it‘s very easy to understand.


----------



## Scribner (Jun 24, 2019)

Yes, k.jacker, that was the thread I saw. I read your post again, and it makes a lot of sense.

Since I'm no longer getting the error message in my original post, do you think everything is working normally without any need for the solution tommiie recommended in his first reply?


----------



## Spartrekus (Jun 24, 2019)

what about  

```
vi /etc/rc.conf
```
 or 
	
	



```
ed /etc/rc.conf
```
 where is hostname in the file.

the dns server will see this hostname, from BSD after reboot, normally.


----------



## tommiie (Jun 24, 2019)

Depends. What does your /etc/resolv.conf file now looks like? Can you ping not only 8.8.8.8 but also google.com? If you can ping DNS names, resolution works and nothing needs fixing.


----------



## Scribner (Jun 24, 2019)

I turned on my computer and got the message again. I went ahead and tried pinging Google anyway, and it worked. I then shut down the computer and turned it back on, and I didn't get the error message. Do you know what this means?

Edit: I also changed my hostname to the name of one of my dogs, per SirDice's above instructions. I am currently installing the Xfce pkg.


----------



## ralphbsz (Jun 25, 2019)

Scribner said:


> I turned on my computer and got the message again.


Which message? Above you have several examples.  Let me assume you are talking about the very first one: "error resolving pool 0.freebsd.pool.ntp.org"



> I went ahead and tried pinging Google anyway, and it worked.


If you can ping 8.8.8.8, then the TCP/IP part of networking is fundamentally working. You can get network packets in and out, if you know the address of the host you want to reach. It may not work 100%, but at least somewhat.

If you can ping google.com (or dns.google, which resolves to 8.8.8.8), then in addition, your DNS client is working. That means your computer is fundamentally able to find IP addresses (like 8.8.8.8) from host names (like dns.google). That in turn means that your /etc/resolv.conf is not completely broken.



> I then shut down the computer and turned it back on, and I didn't get the error message.


You should learn to not use shutdown/restart as a debugging technique. In most cases, it is WAY to heavyweight and time-consuming. In particular, learn how to not hit the power button to stop something. In most cases, it will work fine, but it is a bad habit, since a hard crash has the potential for causing data loss.



> ... and I didn't get the error message. Do you know what this means?


Assuming we're talking about the "error resolving ...ntp.org", it means that not only your DNS works now, it even works right when booting, right when NTP starts first. I have no idea why it didn't work the first time you booted, assuming you didn't change any configuration inbetween. On nasty possibility is that things are still not perfect, and your DNS is right now only intermittent. Perhaps you picked a really bad DNS server in /etc/resolv.conf (use 8.8.8.8, 8.8.4.4, and if those don't work for you, because they may be blocked in certain countries, you can try 9.9.9.9 or 1.1.1.1). Maybe you are using DHCP to get an IP address, and your DHCP server is flaky and sometimes gives you a crazy DNS server address, and then overwrites /etc/resolv.conf. Whenever you have a problem with DNS or name resolution, you should check what /etc/resolv.conf contains.


----------



## hruodr (Jun 25, 2019)

The name you put in /etc/rc.conf is returned by gethostname() function and may become an argument
to a call of a function like gethostbyname(). If it is not DNS resolvable, put it in /etc/hosts near localhost.

Look 21.2.1 in "sendmail" book, I quote it from somewhere in the internet:



> All versions of _ sendmail_ use more or less the same logical process to obtain the canonical name of the local host. As illustrated in the sample program below, _ sendmail_ first calls _ gethostname_ (3) to obtain the local host's name. That name may either be a short name or a fully qualified one depending on which comes first in the _ /etc/hosts_ file. If the call to _ gethostname_ (3) fails, the name of the local host is set to _ localhost_ :
> 
> #include <sys/types.h>
> #include <sys/socket.h>
> ...


----------



## facedebouc (Jun 25, 2019)

Scribner said:


> I recently installed FreeBSD 12.0 and haven't done anything else. I got this message after I booted up, and I suspect it's an error:
> 
> `login Jun 23 10:09:27 machine1 ntpd[1109]: error resolving pool 0.freebsd.pool.ntp.org:hostname nor servname provided, or not known (8)`
> 
> ...


I had to put this in my /etc/rc.conf:

```
#
# NETWAIT
#
netwait_enable="YES"            # Enable rc.d/netwait (or NO)
netwait_if="alc0"               # Interface name to watch link state on.
netwait_ip="192.168.8.1"        # IP addresses to be pinged by netwait.
```
netwait_ip is the IP of my Internet gateway but it could be anything else.


----------



## ralphbsz (Jun 25, 2019)

You said "I had to put ...".  For what? What problem does this solve?

What this does is: If your "internet" (in your particular case the host 192.168.8.1) is down, then your machine won't boot. Or more accurately, it will get hung in the boot process, waiting for the internet to come up. Is that what you want? How are you going to diagnose why the internet is down, when you have no working computer? And isn't your computer also useful if the internet is down? Also consider the asymmetry: If your computer is already running when the internet goes down, it will continue running (except that all internet-related function stops working); it won't shut down. So you have to be able to deal with using it (or at least recognizing the situation) when the internet is down.

For a specific purpose machine, which only makes sense to have running in conjunction with another machine, the netwait mechanism can make sense. For example, you might have a (nearly) diskless client machine that NFS mounts all of its file systems from a server, and if the NFS server isn't up, it is more efficient to delay booting the client than the have it boot and then reach in and fix the mount. But for a general small server or desktop machine, this doesn't sound useful to me; perhaps you have other use cases.


----------



## facedebouc (Jun 25, 2019)

It's for my desktop or laptop use (WiFi), and it solve the problem mentioned upper by scribner (ntpd resolver error).
And no if the network isn't up, the boot process can continue please read rc.conf(5) before replying.


----------



## ralphbsz (Jun 25, 2019)

OK, if you understand why you are doing it, and what really happens, that's great.


----------



## facedebouc (Jun 25, 2019)

For your information I give you last part of my system message buffer at BOOT with and without NETWAIT_ENABLE.
Without NETWAIT_ENABLE:

```
Starting local_unbound.
Waiting for nameserver to start... good
alc0: link state changed to UP
alc0: link state changed to DOWN
Creating and/or trimming log files.
Starting syslogd.
Updating CPU Microcode...
CPU: AMD FX(tm)-6300 Six-Core Processor              (3515.86-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
  AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
  AMD Features2=0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC>
  Structured Extended Features=0x8<BMI1>
  SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=65536
  TSC: P-state invariant, performance statistics
Done.
Additional ABI support: linux.
Clearing /tmp.
Loading kernel iconv modules.
Loading kernel iconv tables.
Updating motd:.
Mounting late filesystems:.
Security policy loaded: MAC/ntpd (mac_ntpd)
Starting ntpd.
Starting powerd.
Starting smartd.
Jun 25 19:13:18 merisier ntpd[908]: error resolving pool 0.fr.pool.ntp.org: hostname nor servname provided, or not known (8)
Starting dbus.
Starting slim.
startxfce4 - Xfce Session
startxfce4 - Xfce Session
Starting musicpd.
Starting sendmail_submit.
Starting sendmail_msp_queue.
Starting cupsd.
alc0: link state changed to UP
Configuring vt: keymap blanktime.
Starting cron.
Starting background file system checks in 60 seconds.
```

With NETWAIT_ENABLE="YES" :

```
Waiting for alc0, interface present
alc0: link state changed to UP
, got link.
Waiting for 192.168.8.1 to respond to ICMP ping
alc0: link state changed to DOWN
alc0: link state changed to UP
, got response.
Starting local_unbound.
Waiting for nameserver to start... good
Creating and/or trimming log files.
Starting syslogd.
Updating CPU Microcode...
CPU: AMD FX(tm)-6300 Six-Core Processor              (3515.86-MHz K8-class CPU)
  Origin="AuthenticAMD"  Id=0x600f20  Family=0x15  Model=0x2  Stepping=0
  Features=0x178bfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT>
  Features2=0x3e98320b<SSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AESNI,XSAVE,OSXSAVE,AVX,F16C>
  AMD Features=0x2e500800<SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM>
  AMD Features2=0x1ebbfff<LAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,XOP,SKINIT,WDT,LWP,FMA4,TCE,NodeId,TBM,Topology,PCXC,PNXC>
  Structured Extended Features=0x8<BMI1>
  SVM: NP,NRIP,VClean,AFlush,DAssist,NAsids=65536
  TSC: P-state invariant, performance statistics
Done.
Additional ABI support: linux.
Clearing /tmp.
Loading kernel iconv modules.
Loading kernel iconv tables.
Updating motd:.
Mounting late filesystems:.
Security policy loaded: MAC/ntpd (mac_ntpd)
Starting ntpd.
Starting powerd.
Starting smartd.
Starting dbus.
Starting slim.
startxfce4 - Xfce Session
startxfce4 - Xfce Session
Starting musicpd.
Starting sendmail_submit.
Starting sendmail_msp_queue.
Starting cupsd.
Configuring vt: keymap blanktime.
Starting cron.
Starting background file system checks in 60 seconds.
```
As you can see without NETWAIT_ENABLE="YES", alc0 is toggling and become UP after starting ntpd which is giving the resolver error.


----------



## Scribner (Jun 26, 2019)

ralphbsz: Thanks for your detailed explanation. You did seem to understand what I was talking about (sorry for not being more specific!). As mentioned in my last post, I changed the `hostname=` in /etc/rc.conf to the name of one of my dogs (which is not a domain name). Since I made this change, I don't believe I've gotten the message in my original post; but I will be on the lookout for it (I believe I've only booted my computer a few times since this change).

I was wondering, what kind of data loss does hitting the power button to stop something ("a hard crash") cause? I try to shut down using `# shutdown -p now` whenever possible. Interestingly, the reboot command, `# shutdown -r now`, does not seem to work on my computer. While it reboots the computer, it then just stays on the screen with the Lenovo logo. The only thing I can think of is it has to do with when I disabled SecureBoot in the computer's BIOS in order to get the bootable FreeBSD USB stick to work. But this is probably for a whole new thread at some point...


----------



## ralphbsz (Jun 26, 2019)

Data loss: On Unix, when a program (perhaps on orders from a human) writes a file, that file is not necessarily on disk. The write call puts the file in memory, and even closing the file does not always force it to disk. This is vitally necessary for good performance. Written files stay in memory for typically 5-30 seconds (can be much shorter on a busy system). If you simply hit the power switch during that time window, the most recent writes to the file can vanish. For a small file, it means all of the content can vanish (leaving you with an empty file), or the whole file may vanish (there is not even a directory entry for it). For a large file that was being written or worse updated, you may end up with an inconsistent version of the file, partially written.

So that right there is one example of data loss. And it is completely designed in, and documented.

Programs that really care obviously can work around this. For example, many programs need to know that written data is "stable", meaning expected to survive a crash, before they give feedback to another party. In CompSci theory, you would describe this as making the data durable before allowing side effects of the write to occur (get a good database textbook, and read up on ACID properties). One way to do it: First do the write, then call one of the functions in the fsync() family, wait for it to return without error, and only then tell anyone else that you are done with the write. Most programs don't do this, because it kills performance (the fsync() call has to wait for the disk hardware, and with spinning disks that will by its nature take many ms). So if you just edit a file and save it, and within a second or two hit the power switch, you better not have high expectations that your edits will actually make it. (Actually, reputable editors do tricks with keeping backup copies, and leaving breadcrumbs for themselves, so in many cases when re-editing it the next time, the will either have your previous edits, or they will be able to tell you that something was lost.)

The other version of the same effect is file system corruption. Fundamentally the same effect, but now internal to a file system. For example, imagine you just created a new file /usr/home/ralph/foo.bar, and wrote to it. That operation needs at least four parts: Create a directory entry in /usr/home/ralph that says that file name foo.bar is associated with a certain file, let's call it inode number 123456. And update that directory on disk to have that information stored. Second, create a data structure on disk that describes the file, saying this file was created on Wednesday at 11:45, and the actual raw data is on disk /dev/hdxx starting on sector 98765 and is 42 bytes long. Third, allocate space for sector 98765 and mark it as used in some allocation table. And fourth and finally, actually write the data "the quick brown fox..." to that sector. A good file system will perform these operations in such a way that at no point there is an inconsistency, even if the overall flow is interrupted somewhere in the middle. One example of an inconsistenty would be: Do all steps except the last one, and the old content of the sector was "to be or not to be". Then after a reboot, someone would find the file name in the directory, it would point to the correct inode and sector, but the content would wrong, it's supposed to be "the quick brown fox", and the disk still contains "to be or not to be".

Today, good file system implementations are pretty good about doing these complex operations in such a way that they never create inconsistencies. After a crash, you will either find the correct file with the correct content, or you will find nothing. But this is an extremely difficult problem to solve, and file systems have not always been this good. The extremely broken case (they give no error message, but return "to be or not to be") is fortunately rare; more common forms are instead that you get an error message when trying to read the file, or your system crashes when you try to read it, or the system refuses to mount the file system because it is inconsistent, or you have loss of capacity (for example if the space is already allocated for the new file, but the new file was actually never created, so some disk space becomes permanently wasted).

The techniques for doing these file system updates consistently (read about ACID properties!) are very hard, if you want to also have good performance, and maintainable and intelligible code. For many decades, real-world production file systems didn't solve this problem. Matter-of-fact, one of the great milestones in this field was Kirk McKusick's paper on Soft Updates (Usenix 1999 or 2000, I think it was the one in Monterey), which found a way to maintain both consistency and performance by figuring out which internal writes need to be synchronous and which ones don't; by the way, the work he describes is in FreeBSD's UFS file system. ZFS also solves this problem quite nicely, going back to a different tradition (the log-structured work from the 80s). Many older file systems are known to have corruption, leakage and loss problems when writes are prevented by crashes, but on a normal FreeBSD system with UFS and ZFS one shouldn't worry about that too much. Still, having spend decades implementing file systems, I would prefer that people NOT crash their machines randomly, because even the best-intentioned code may have bugs. And buy UPSes.

So, please don't crash your machine if you can avoid it. It's playing with fire.


----------

