2. page content

Content

Continuation

Az on the first page we installed the base system, did the basic settings and installed it ISPConfig control panel and the necessary ingredients. On this page, we create the primary web account and email account, then we use an external, free service to use secondary name servers, and finally we redirect the domain name to our server, making it accessible from the outside.

Create a primary web account

Our first task is to create a primary web account. This web account is technically no different from other web accounts - which will be created later - the only difference is that this account "belongs" to the server domain name create it, so that we can then direct it through which our main website, our ISPConfig control panel and our other web services become available. Therefore, this account is only worth distinguishing from this point of view. The main domain name, on the other hand, has a privileged role in that this name is included in the full hostname, i.e. the server FQDN on behalf of which will be important in several places.

I will not go into full detail about the creation of the ISPConfig web account here, as I have already prepared a separate description for this, which can be found here:

• Creating the first Web account in the ISPConfig server configuration

Here, I will highlight only those parts that contain more important settings from the point of view of this description, so that in the end we have a working server.

Create a client

The ISPConfig client is a separate user level that allows us to manage our web accounts and services in a more sophisticated way. Its use is not mandatory, but if we are thinking in the longer term and several web accounts, it should be considered. I create my own client and add the primary account to it. Of course, if I will also manage that account. It is therefore up to everyone to create it. If you want to create your first, own customer, you can see the process at the link above. Here, I'm only showing one picture of my settings process.

For the client, what might be worth highlighting is the cron part, which can be found on the Limits tab under the "Cron Job Limits" drop-down:

Here, it is worth setting this to Full Cron, so that later you can avoid hassles when setting cron tasks, as well as setting the minimum time interval to 1, so that you can also set cron tasks every 1 minute with the client.

The rest of the settings can be found in the description linked above, we will not expand this further here.

Deactivating prefixing of usernames

ISPConfig prefixes usernames with the client's ID or name. We can turn this off if we want, you can read about it here:

• Disable prefixing of user names in the ISPConfig3 control panel

Here, after reading the above, let's decide whether to leave the prefixes or turn them off. This decision must be made here, as the prefixing settings affect the creation of additional ISPConfig structures (e.g. database, shell, etc. for user names, etc.). As usual, I turn off these prefixes here as well.

Create a Web account

You can also read about the detailed process of creating a web account in the first web account creation description in the link above. Here, too, we will only quickly run through the most important parts, so we will not expand on every small setting option here either. So here we skip some tabs, we don't have anything to do with them yet, and we'll come back to some later when, for example, we have SSL-our, etc.

So let's go to the Websites main menu, and click on the green "New website" button on the Websites sub-menu (this is included by default), and the creation of the web account can begin.

Domain tab

• Server: the FQDN name of our server, it is set by default.
• customer: If you have created a client, set it up here
• IP address: *
• IPv6 address: empty, or if our dedicated server/VPS provider provides an IPv6 address, we can set it. But in order to avoid mischief, let's not force it. (Today's age is not yet ripe for the use of IPv6 addresses, for now in most places it only causes more trouble than it would be useful.)
• Domain: Set the primary domain name here. In my case, this is "linuxportal.eu". So here you only need the domain name, without subdomain/hostname.
• Limits: -1
• Required ticks: Own error page, nothing else is needed
• Auto Subdomain: www.
• SSL: no (we will solve this later, we will not set it for now)
• Let's Encrypt: Also not.
• PHP: PHP-FPM
• PHP version: It depends on the website you want to run on the primary hosting. If, for example, it was kept up to date CMS system, such as this Drupal 9 page, then 8.1 is already supported by all well-known CMSs, but if a thousand-year-old website, such as my "old" nokiaprogramok.hu my website, then 5.6 is correct.
• Web server configuration: -
• Active: again.

Settings tab

Skipping the other tabs, we run through the Settings tab page. The fields I don't mention are left at the default value, as you can see in the pictures.

• Use Socket For PHP-FPM: Yes (default)
• PHP-FPM Process Manager: dynamic

So here we only have to change these, the other basic settings will be fine.

Save the form, our first web account is ready.

Check web hosting

If we have waited until the little red circle above disappears, we can also check the web hosting by going to the www address:

http://www.linuxportal.eu/

Here, of course, there is still only a simple HTTP connection, but the website is already there, which in this case is such a welcome panel.

Create a hostname subdomain

We also need to create a subdomain for the server's hostname under the primary domain name connected to our server, which is necessary from several points of view:

• This gives the FQDN of the server, which includes the hostname and the primary domain name in one. This is issued by hostname -f command too.
• If it is set, ISPConfig requests a separate SSL for this, which will also be the SSL for the control panel and the main services (this SSL is not the same as the SSL issued for the website, separate SSLs are issued for them) .
• The PTR record will have to be set later at the service provider, which also requires this FQDN name. This will be needed towards the end of the description.
• Also, if it is set, the server's web applications, such as webmail, phpMyAdmin, Monit, etc., can be conveniently accessed through this. Currently we can only access them by setting our hosts file, but from elsewhere these addresses won't work without it

To create a subdomain, go to ISPConfig sites to the main menu, then select here Subdomain for website menu item and click on it Add new Subdomain Next:

And the settings are:

• Station: Here we enter the hostname of our server, which we set at the very beginning. This is plain hostname we can also get it to order. It's "vps" for me.
• Domain: Since we are now installing the server, by default our only domain name is displayed here followed by the full host name. For me: "linuxportal.eu :: vps.linuxportal.eu".
• Redirect Type: No redirection. We will use this to access web applications, among other things, where there is no need to redirect anywhere.
• Redirect route: Empty. (If we set them here, we would not be able to load phpMyAdmin at this address, for example, because it would redirect the browser to the set address)
• Don't add to Let's Encrypt certificate: there is no tick. The point here is that we request a separate SSL for this subdomain as well.
• Active: pipe.

There is currently nothing on the settings tab, maybe they are developing something here, but there is nothing there now.

Save the form, we're done here.

Email settings

In this chapter, we will create an email domain and add an email account. This is a necessary part of live operation, as many registrars require the existence of a technical contact email address, without which they will not allow you to redirect the domain. I wrote about creating an email account before in the first web account article, but we will run through it here as well.

Creating an email domain

First, we need to create an email domain, for which we will then create an email account. Let's do this Email to the main menu, where it is immediately Email Domain menu welcomes us:

By definition, this is still empty, click here New Domain button.

Settings:

• Server: Our own server should appear here.
• Client: If you created a client at the beginning, set it here.
• Domain: Enter the primary domain associated with our server. Which we have already mentioned a lot.
• Spam filter: I don't usually use this. I prefer to leave spam filtering to the mail client running on my machine. But this is also a matter of personal taste, it has no importance from the point of view of sharpening the server.
• Active: kite

Save the form.

Create an email account

Right there, it is Email while staying in the main menu, click on email correspondent to the chest menu:

Even this is empty, let's click here as well Create an email account Next:

Settings:

• Name: We can enter anything here, but here we will create an administrative account, so I will name it "Admin"
• Email: I also create an admin@ address here, and this will also be set in the DNS zone.
• Password and repeat: Enter a password here. It measures its strength between the two fields.

From here on, leave the other parts as they are by default and save the form. We don't need to deal with the other ears here either.

We are done with these email parts. With this account, we can also access the webmail interface, but now we will go further and check everything at the end.

Creating a DNS zone and setting records

In this chapter - from the point of view of arming the server - we will perform one of the most important parts, a DNS creation and setting of the zone and the records in it. The necessary theoretical parts for this can be found on the DNS link just mentioned, and here are the settings.

Domain redirection is performed on a name server basis, when the domain SOA record it comes to us. In order to transfer the domain name to our server, you must first create the DNS zone for the domain and set the records in it. If we have this, our own server will be our primary name server as well.

Create a DNS zone

Let's go to ISPConfig DNS to the main menu, where the zones we get to the menu:

Let's click here Add new DNS Zone with Wizard button. This creates a base of records for us, so we don't have to upload every record from scratch. First, we set the SOA record itself:

Settings:

• template: Default
• Server: Our own server should jump in here
• customer: If you created your own client at the beginning, set it up here.
• Domain: Enter your primary domain name. For me, this is linuxportal.eu
• IP address: Let's set the IP address of our server. The system also pops this up in the drop-down menu.
• NS1: Primary name server. This will be our own server, for which we will also create a subdomain record. So let's set ns1 here now. value.
• NS2: If we don't have a secondary name server, or we don't know how to get one, then set up the c.ns.buddyns.com address, and then we will review how we can get a secondary name server for free.
• Email: Here we enter our administrative contact email address, which we created above. Enter it here properly with the @ character, the panel will transform it as it needs.
• Sign zone: nem

When you're done, click on Create a DNS record button.

If we have saved it, the interface jumps back to the list, where the zone we just uploaded is already listed as an item:

The number 8 in the red circle above indicates that ISPConfig has a lot to do, it creates the zone and the basic records in it with the help of the wizard mentioned above. If the red circle has disappeared, click on our new zone and we can start setting records.

Setting records

If we opened the zone, we get a basic setting like this in the first round:

Now we need to set these records so that we get the following list:

------------------------------------------------------------------------------------------
Aktív	Típus	Név							Adat						Prioritás	TTL
------------------------------------------------------------------------------------------
Yes		A		linuxportal.eu.				178.238.208.205				0			3600	
Yes		A		mail.linuxportal.eu.		178.238.208.205				0			3600	
Yes		A		ns1.linuxportal.eu.			178.238.208.205				0			3600	
Yes		A		vps.linuxportal.eu.			178.238.208.205				0			3600
Yes		A		www							178.238.208.205				0			3600	
Yes		MX		linuxportal.eu.				mail.linuxportal.eu.		10			3600	
Yes		NS		linuxportal.eu.				ns1.linuxportal.eu.			0			3600	
Yes		NS		linuxportal.eu.				c.ns.buddyns.com.			0			3600	
Yes		NS		linuxportal.eu.				j.ns.buddyns.com.			0			3600	
Yes		TXT		linuxportal.eu.				v=spf1 mx a ~all			0			3600

So you need a total of 10 records. According to the list above, we should configure ours exactly so that we have such records with our own domain and host names and IP addresses. And don't forget the periods after the names. Unless it has only one subdomain in itself, as in the case of "www". but we can even enter it with a full name and a period at the end.

I already wrote about this setting here:

• How to set up a secondary nameserver if we only have one IP address - Error 2/What to do: BuddyNS nameserver is not declared in our zone

When we are done with the settings, our list should look like this:

If everything is fine here, we still have to go back to the zone settings. For this, the above Zone settings we have to click tab

Setting zone transfer IP addresses

If we switched to the Zone settings tab, we will return to our first set panel, only now with many more setting options that were not on the form at that time. So here we can set the parameters of our SOA record:

The only important thing here, and I have already filled it in, as you can see in the picture, is that Allow zone transfers to these IPs (comma separated list) field. The IP addresses for which the zone transfer is allowed, i.e. the AXFR operation, must be entered here.

These IP addresses are the servers of the service provider that provides our secondary name servers, who retrieve a copy of our zone when necessary and thus provide us with secondary name servers.

I will not describe these addresses here on purpose, as I did not in the old description, as they change from time to time. Some addresses will be removed from it, others will be added to the list. So if I write them down here now, this list would be inaccurate a year from now, and then, for example, our bind DNS server would throw the following error messages:

vps named[865356]: client @0x7f0744025b00 193.109.120.66#45255 (linuxportal.info): zone transfer 'linuxportal.info/AXFR/IN' denied

This happened to me recently. Servers that were not in my list attempted the zone transfer. So I had to check BuddyNS's list again, and sure enough, there were new IP addresses.

So now I'm linking here to the subpage from which we can get this IP address list up to date:

• https://www.buddyns.com/support/setup/zone-transfer/free/

Here, click on the Other tab:

Here, copy the IPv4 addresses, then compile a comma-separated list of them, and insert it into the ISPConfig Zone transfer field.

Add IP addresses listed with line breaks to a comma-separated list Easter command, where we copy the list from the clipboard between echo quotation marks:

echo "<IP-cím 1>
<IP-cím 2>
<IP-cím 3>
<IP-cím 4>
<IP-cím 5>" | paste -s -d, -

So I'm not copying the addresses right here, because then it wouldn't be fresh in half a year or a year. In this way, everyone can copy the latest addresses from the given page and convert them into a list.

Once these IP addresses have been set, save the form.

Create and configure secondary name servers

As I mentioned above, I will now elaborate a bit on this secondary name server thing here.

In order for domain names to function properly, several name servers are needed to ensure the smooth availability of services. The registrars will not allow you to switch your domain's nameservers if they are not properly configured or do not contain a secondary nameserver.

If we rent a shared hosting somewhere, this is not a problem there, because the service provider provides the name servers for the hosting. You only need to point the domain to the name servers provided by the hosting provider, and they are always updated when the DNS records in the hosting control panel are changed. In this case, the service provider solves this. This is not the case when renting a VPS or dedicated server, since the internal content of the server is not monitored by the service provider, so in this case we have to take care of it ourselves. Even though we install the ISPConfig control panel, the system is not connected to the service provider's own name servers, so the records are not copied.

There are several solutions to this question, the free service of BuddyNS, which provides 300.000 DNS queries per month, has worked for me for years. Of course, it is difficult to do with this information at first, but let's consider that such a DNS query occurs when, say, someone wants to visit one of our websites from somewhere in the world, but at that moment, our primary name server is not accessible from that point. Then the network turns to the secondary name servers with the retrieval, which help to bridge this temporary unavailability. Therefore, this 300.000 DNS requests per month is not so little. Especially if you skillfully take advantage of the fact that you register a separate account for each domain name, so that they do not add up in one account, but each domain has a monthly limit of 300.000.

I've been using this since the day the previous article about BuddyNS was written, i.e. from 2018.04.26, and I haven't had any problems with it so far. In addition, they also have good little DNS analysis tools, which can be used to easily detect various configuration errors.

So this might be enough, and now if we want to set up our secondary name server with this, all we have to do is register on the BuddyNS page:

• https://www.buddyns.com

BuddyNS account overview, service settings

I will not explain the process in full detail here, because I described it in detail at the time, so the old description again:

• How to set up a secondary name server if you only have one IP address

Here we are just going through the main parts.

First, we have to register, where we have to enter an email address, the domain name and the master server, i.e. the IP address of our server, where we have the SOA record and also our primary name server. After logging in, the main menu items:

Dashboard

The home page of the account after registration:

Zones

Here we can see the set zone:

Here, after the domain name that appears in red, there is a small crosshair-like icon, click on it, and then the blue strip and the parts below it will open.

Here we now interpret the status:

A wide red line at the top indicates that there is 1 error. The red color of the domain name below also indicates this. Then, going further down, point by point, there are the following:

• Status: INACTIVE. Inactive state, that's fine now
• Submitted on: Here you indicate the time of registration. There is a slight time zone difference here.
• Last updated on: Here it will indicate the time of the last update. It has not yet been updated due to the error
• Master declares BuddyNS: OK. This is indicated by the BuddyNS link in the master zone. We set this above in our own DNS zone, right?
• Authority declares BuddyNS: ERROR
• Registry declares BuddyNS: ERROR. These two "connect" together. The essence of these is that the registrar does not have the link to BuddyNS.

The part below the blue line:

• Status: Complete. Successful test query results.
• UDP queries: OK. UDP test queries from our DNS server were successful 
• TCP queries: OK. TCP test queries from our DNS server were also successful
• AXFR queries: OK. AXFR queries from our DNS server were also successful.

All in all, all you have to do now is to go to the registrar's page and configure the name servers there. Everything else is perfect so far.

Changing name servers at the registrar

Before switching the name servers, let's look at a ping statistic.

View ping statistics before migration

There is a good ping page for this purpose, I use this one:

• https://www.host-tracker.com/en/ic/ping-test

Enter the target domain name here, and it will ping you from more than 100 servers around the world. In this way, we get an accurate picture of the update of the name servers.

We will not deal with the Bad and Fail states here, because dotroll's IPv4 nameservers cannot be pinged properly even from a terminal, because the packets are dropped. They are probably blocked directly. But what is enough for us is to see the IPv4 address, and of course there is also IPv6 here, but this is only temporarily, until I redirect it to my own server, where there will only be an IPv4 address.

Switching name servers

I have this domain name set up at Dotroll. The name servers must be specified here on the interface:

So I have the three name servers, this is the list after the entered state:

• ns1.linuxportal.eu - primary
• c.ns.buddyns.com - secondary
• j.ns.buddyns.com - secondary

The order displayed here does not matter, during name resolution the system also knows where the primary name server is with the SOA record, etc.

As well as the primary, our own name server must first be specified with an IP address, since the domain is still new, so if we refer to it with itself, the name servers will not recognize it.

Here, it may not accept the entered nameservers at first, in which case you have to persistently resend them, and then it just accepts them. But there are also cases where it is not accepted for many times, in which case you have to write to the customer service and they will set it up. Of course, in this case, we should check everything beforehand to make sure everything is in order.

BuddyNS zone recheck

If we look back at the BuddyNS interface again and refresh it, as well as click on the small crosshair icon to open the control section, we can already see a flawless zone:

I continued this the next day, because it was late at night, but this part will be updated immediately, since in this case BuddyNS directly requests the data from the registrar, so it does not wait for the name servers of the wider world, but it is now the name server source, which passes on the relevant DNS data for these public name servers, whose task is to update them everywhere from now on. So now you have to wait here until it is updated everywhere to the new IP address.

View ping statistics after migration

After we have successfully switched the nameservers, we then need to wait a little while for the nameservers everywhere to refresh. Earlier in one country/city, later in another, etc. But in general, after about 1-2 hours, about 80% of this list already shows the new IP address. Here it is also worth waiting for this process, because it may have already been updated at our own internet provider, but for example if we want to request Let's Encrypt SSL certificates, it throws an error because it has not been updated in their network yet, so you don't see it yet the server. So it is worth waiting until at least the vast majority of these ping servers show the new address.

In the meantime, we look at a state:

It still contains traces of old IP addresses from Dotroll, but it mostly points to its own server. There are a few old titles even further down, so I'll wait a little longer...

While the nameservers are being updated, I retrieved my previous ISPCponfig cron log, which the /var/log/ispconfig/cron.log I read it from a file. I recently moved my websites too, and there were times when I set up the Let's Encrypt certificate on the website too soon, but it always removed the tick from the checkbox. Then I looked into the cron log and found something like this:

Thu Jan 5 04:59:03 CET 2023 05.01.2023-04:59 - WARNING - Could not verify domain linuxportal.info, so excluding it from letsencrypt request.
Thu Jan 5 04:59:03 CET 2023 05.01.2023-04:59 - WARNING - Could not verify domain www.linuxportal.info, so excluding it from letsencrypt request.
Thu Jan 5 04:59:03 CET 2023 05.01.2023-04:59 - WARNING - Let's Encrypt SSL Cert for: linuxportal.info could not be issued.

In such cases, what happens is that ISPConfig itself has not yet seen the domain directed to it from the server, so it skipped the retrieval of the certificate. 

I write all this just for the sake of interest, that if such an error appears in the log, it only means that the server does not detect the correct IP address for the given domain. So you have to try later, or you can "speed up" this process a bit by setting a temporary setting in our hosts file.

Meanwhile, a more recent ping status:

And here the new IP address appears everywhere, even further down. So you can say that it is 100% updated based on these samples.

If everything went well, the IP addresses were updated, then a next page we continue with checking and further settings and fine-tuning of the server.

Navigation