Installing Android Things on Raspberry Pi 3 B+

https://developer.android.com/things/hardware/raspberrypi

Download the Console Tools from the following link. You will need to sign into your Google account.

https://partner.android.com/things/console/#/tools

Unzip the file and Launch the correct utility for your OS.

On Windows you will need to launch as administrator by right clicking on the Windows Application and Run as administrator.

Run as administrator

The program is easy to follow along with and automatically downloads and creates the SD card for the Pi.

After you are finished, put the card in the Pi and boot it up.

WHM/cPanel – Change Main Server IP

Change IP Address from command line

Open up the following file, change eth0 to your primary ethernet adapter. More info here.

 vi /etc/sysconfig/network-scripts/ifcfg-eth0

and under IPADDR set it to the new IP. Update netmask and gateway if needed.

Save file and restart network

systemctl restart network

Update License

You may need to run the following to update the license on the server.

/usr/local/cpanel/cpkeyclt

Change Server IP in WebHost Manager

Change IP for server in Basic WebHost Manager Setup

Other things to do

You may need to migrate IP’s to the new address.
If you are keeping the old address on the server, then you may need to readd it through the IP Functions.

WHM/cPanel – Works from some networks and not others.

Had a problem with a WHM/cPanel server where it was working fine from a couple different networks, but then would not work on others. The server itself seemed fine and fully operational.

Checked firewall rules on routers, server, checked IP routes, tried disabling cPHulk. Ended up being there were a couple addresses added with the incorrect subnet mask which was keeping it from working. Removed the IP’s with the wrong subnet and it started working on all networks.

[root@host ~]# ifconfig
eth0: flags=4163 mtu 1500
  inet 192.168.1.70 netmask 255.255.255.224 broadcast 192.168.1.95
  inet6 7f80::4588:523f:a697:c311 prefixlen 64 scopeid 0x20
  ether 4b:02:de:0d:cf:1a txqueuelen 1000 (Ethernet)
  RX packets 171071 bytes 83556877 (79.6 MiB)
  RX errors 0 dropped 0 overruns 0 frame 0
  TX packets 163710 bytes 76482245 (72.9 MiB)
  TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

eth0:cp1: flags=4163 mtu 1500
  inet 192.168.1.74 netmask 255.255.255.224 broadcast 192.168.1.95
  ether 4b:02:de:0d:cf:1a txqueuelen 1000 (Ethernet)

eth0:cp6: flags=4163 mtu 1500
  inet 192.168.1.75 netmask 255.255.224.0 broadcast 23.145.159.255
  ether 4b:02:de:0d:cf:1a txqueuelen 1000 (Ethernet)
…

[root@host ~]#

Under eth0:cp6 the IP has a 255.255.224.0 subnet which is incorrect. Should have been a 255.255.255.224 (/27) subnet.

Removed the IP out of WHM and then readded with the correct subnet mask and it now works.

Make sure you add and IP with the correct subnet

cPanel/WHM enable shell_exec

SSH into WHM server

ssh root@cpanel.host.com

Modify Website php-fpm Config File

Edit the following config file. Replace “website.com” with the website your enabling the shell_exec for

vi /opt/cpanel/ea-php72/root/etc/php-fpm.d/website.com.conf

Locate the following line and remove shell_exec from the list of disabled_functions

php_admin_value[disable_functions] = exec,passthru,shell_exec,system

The line should look like the following

php_admin_value[disable_functions] = exec,passthru,system

Restart Apache PHP FPM Service

Save the file and restart the apache_php_fpm service

/scripts/restartsrv_apache_php_fpm

Followed from

Named Debugging Levels

In the following command, x should be the debug level number

named -g -d x

Example,

named -g -d 3

Following info taken from here.
https://docstore.mik.ua/orelly/networking/dnsbind/ch12_01.htm

12.1.1 What Information Is at Each Level?

Here is a list of the information that each debugging level will give. The debugging information is cumulative; for example, level 2 includes all level 1’s debugging information. The data are divided into the following basic areas: starting up, updating the database, processing queries, and maintaining zones. We won’t cover updating the name server’s internal database – problems always occur elsewhere. However, what the name server adds or deletes from its internal database can be a problem, as you’ll see in Chapter 13, Troubleshooting DNS and BIND .

Level 1

The information at this level is necessarily brief. Name servers can process lots of queries, which can create lots of debugging output. Since the output is condensed, you can collect data over long periods. Use this debugging level for basic startup information and for watching query transactions. You’ll see some errors logged at this level, including syntax errors and DNS packet formatting errors. This level will also show referrals.

Level 2

Level 2 provides lots of useful stuff: it lists the IP addresses of remote name servers that are used during a lookup, along with their round trip time values; it calls out bad responses; and it tags a response as to which type of query it is answering, a SYSTEM (sysquery) or a USER query. When you are tracking down a problem with a secondary server loading a zone, this level shows you the zone values – serial number, refresh time, retry time, expire time, and time left – as the secondary checks if it is up-to-date with its master.

Level 3

Level 3 debugging becomes much more verbose because it generates lots of messages about updating the name server database. Make sure you have enough disk space if you are going to collect debugging output at level 3 or above. At level 3, you’ll also see: duplicate queries called out, system queries generated (sysquery), the names of the remote name servers used during a lookup, and the number of addresses found for each server.

Level 4

Use level 4 debugging when you want to see the query and response packets received by the name server. This level also shows the credibility level for cached data.

Level 5

There are a variety of messages at level 5, but none of them are particularly useful for general debugging. This level includes some error messages, for example, when a malloc() fails, and a message when the name server gives up on a query.

Level 6

Level 6 shows you the response sent to the original query.

Level 7

Level 7 shows you a few configuration and parsing messages.

Level 8

There is no significant debugging information at this level.

Level 9

There is no significant debugging information at this level.

Level 10

Use level 10 debugging when you want to see the query and response packets sent by the name server. The format of these packets is the same format used in level 4. You wouldn’t use this level very often, since you can see the name server response packet with nslookup .

Level 11

There are only a couple of debugging messages at this level, and they are in seldom-traversed code.

How To Increase Session Timeout for SSH

From the server side, edit the /etc/ssh/sshd_config

Change, uncomment, or add

ClientAliveInterval 120
ClientAliveCountMax 15

Change the AliveInterval and CountMax as desired.

More info on the AliveIntercal and CountMax.

ClientAliveCountMax Sets the number of client alive messages which may be sent without sshd(8) receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. It is important to note that the use of client alive messages is very different from TCPKeepAlive. The client alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The client alive mechanism is valuable when the client or server depend on knowing when a connection has become unresponsive.

The default value is 3. If ClientAliveInterval is set to 15, and ClientAliveCountMax is left at the default, unresponsive SSH clients will be disconnected after approximately 45 seconds. Setting a zero

ClientAliveCountMax disables connection termination.ClientAliveInterval Sets a timeout interval in seconds after which if no data has been received from the client, sshd(8) will send a message through the encrypted channel to request a response from the client. The default is 0, indicating that these messages will not be sent to the client.

More information
https://man.openbsd.org/sshd_config