We have a NTP client configured on one of our system.
The client has a set of servers available with whom it can synch with.
However the preferred server that we chose is our internal master server with IP 169.254.1.51.
The contents of ntp.conf for same are below :-
# --- CLIENT NETWORK -------
# --- USER SETTINGS BEGIN ---
server 10.241.34.2 iburst
server 10.241.34.3 iburst
server 10.241.34.4 iburst
restrict 10.241.34.2 mask 255.255.255.255 nomodify notrap noquery
restrict 10.241.34.3 mask 255.255.255.255 nomodify notrap noquery
restrict 10.241.34.4 mask 255.255.255.255 nomodify notrap noquery
# --- USER SETTINGS END ---
# --- NTP MULTICASTCLIENT ---
restrict 169.254.0.0 mask 255.255.0.0 nomodify notrap # internal network
# --- INTERNAL TIMESERVERS BEGIN-----
server 169.254.1.51 burst iburst minpoll 4 maxpoll 6 prefer #Internal master Server
# --- GENERAL CONFIGURATION ---
server 127.127.1.0 iburst minpoll 4 # local clock
fudge 127.127.1.0 stratum 10
tinker step 0
The above is for the configuration part.
However when we check the syslog after configuration and restarting system, We found that client is synchronizing with external server instead of prefer server as captured in ntpq output in syslog
Mar 22 05:52:48 Node ntpcheck: remote refid st t when poll reach delay offset jitter
Mar 22 05:52:48 Node ntpcheck: ==============================================================================
Mar 22 05:52:48 Node ntpcheck: *10.241.34.2 10.240.33.1 4 u 2 64 1 0.192 -519.50 5.769
Mar 22 05:52:48 Node ntpcheck: 10.241.34.3 10.241.34.2 5 u 1 64 1 0.172 -523.79 8.912
Mar 22 05:52:48 Node ntpcheck: 10.241.34.4 10.241.34.2 5 u 2 64 1 0.207 -520.73 8.082
Mar 22 05:52:48 Node ntpcheck: 169.254.1.51 LOCAL(0) 11 u 1 16 1 0.113 -0.043 2.099
Mar 22 05:52:48 Node ntpcheck: 127.127.1.0 .LOCL. 10 l 14 16 1 0.000 0.000 0.001}
Further the below message message was continuously flooding in syslog
Mar 22 06:51:11 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:51:27 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:51:45 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:52:03 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:52:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:52:35 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:52:51 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:53:06 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:53:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:53:23 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:53:38 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:53:53 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:54:11 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:54:29 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:54:47 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:55:02 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:55:20 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:55:21 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:55:35 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:55:53 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:56:10 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:56:28 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:56:46 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:57:03 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:57:21 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:57:38 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:57:54 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:58:09 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:58:24 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:58:42 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:58:59 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:59:15 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 06:59:30 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 06:59:46 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
Mar 22 07:00:02 Node ntpd[31292]: synchronized to LOCAL(0), stratum 10
Mar 22 07:00:17 Node ntpd[31292]: synchronized to 10.241.34.2, stratum 4
We tried to check on NTP forums and identified that it uses below parameter in defining the server to be prefer synching with
(Reference:- https://www.eecis.udel.edu/~mills/ntp/html/warp.html) :-
First level of rejection happens based on offset and delay.
Then after rejecting the pool, the survivors are passed to clock clustering algorithm.
The clustering algorithm depends on jitter to decide.
The remaining all servers are selectable survivors, any one of them can be choosen.
Now the role of prefer keyword come into play, and all selectable are checked and prefer one is choosen.
If the survivor is not present, then migration rule decide the peer.
However in the ntpq output the prefer server has better offset and jitter, even then it is not chosen.
Is it possible to identify that on what basis it is rejecting preferred server in this case.
Related
I have a Corsair HX1000i PSU, but looks like I can't quite get information for it in the vfs /sys/class/hwmon*; this is my output:
ema#scv:~$ ls -la /sys/class/hwmon/
total 0
drwxr-xr-x 2 root root 0 Jan 21 20:22 .
drwxr-xr-x 85 root root 0 Jan 21 20:22 ..
lrwxrwxrwx 1 root root 0 Jan 21 20:22 hwmon0 -> ../../devices/pci0000:00/0000:00:01.2/0000:01:00.0/0000:02:02.0/0000:03:00.0/nvme/nvme0/hwmon0
lrwxrwxrwx 1 root root 0 Jan 21 20:22 hwmon1 -> ../../devices/pci0000:00/0000:00:01.3/0000:0d:00.0/nvme/nvme1/hwmon1
lrwxrwxrwx 1 root root 0 Jan 21 20:22 hwmon2 -> ../../devices/pci0000:00/0000:00:18.3/hwmon/hwmon2
lrwxrwxrwx 1 root root 0 Jan 21 20:22 hwmon3 -> ../../devices/virtual/thermal/thermal_zone0/hwmon3
My device is revision 2, id: 1b1c:1c1e (I can see it in lsusb):
...
Bus 001 Device 003: ID 1b1c:1c1e Corsair HX1000i Power Supply
...
And I'm running on Ubuntu 22.04 - which is using kernel 5.15.0.
Looking at the kernel sources seems like rev 2 of my PSU is only supported from kernel 6.1 forward in terms of appearing in hwmon* vfs.
Am I correct in expecting this adaptor to appear in this vfs once my kernel gets updated to 6.1+?
What shall I do if I want to query this device myself now? Shall I just use the hid part of the driver to communicate with the low level USB interface?
Is there any library to facilitate USB I/O on Linux (happy to write - or borrow - c code)?
I guess libusb should do whilst I wait Ubuntu to update the kernel?
Thanks!
In a fresh Debian 11 container I installed urbackup.
In the container the uid/gid from urbackup is 107/115.
I needed to bind mounted a zfs dataset to store the actual backups..
Therefore I changed in lxc the urbackup user/group.
root#urBackup:~# usermod -u 1005 urbackup
root#urBackup:~# groupmod -g 1005 urbackup
It seems though that some directory's stil had old uid/gid
root#urBackup:~# ls -al /var/urbackup
total 108012
drwxr-xr-x 3 nobody 115 4096 Apr 19 05:54 .
drwxr-xr-x 12 root root 4096 Apr 19 05:46 ..
-rwxr-x--- 1 nobody 115 35044777 Apr 19 05:47 UrBackupUpdate.exe
-rwxr-x--- 1 nobody 115 40 Apr 19 05:47 UrBackupUpdate.sig
-rwxr-x--- 1 nobody 115 102 Apr 19 05:47 UrBackupUpdata.sig2
Is there a easy way to change also the directory's and files belonging to a certain user/group.
Thanks for reading
Guy
The code is:
#include <stdio.h>
#include <time.h>
int main(void)
{
time_t t, nt; /* seconds time holder */
struct tm gmt; /* time structure gmt */
struct tm lcl; /* local time structure */
t = time(NULL); /* get seconds time */
gmtime_r(&t, &gmt); /* get gmt */
localtime_r(&t, &lcl); /* get local */
printf("gmt hour: %d local hour: %d\n", gmt.tm_hour, lcl.tm_hour);
}
The run is:
samiam#samiam-h-pc-2:~/projects/petit_ami$ gcc -o test test.c
samiam#samiam-h-pc-2:~/projects/petit_ami$ ./test
gmt hour: 20 local hour: 20
samiam#samiam-h-pc-2:~/projects/petit_ami$ date
Sat 17 Jul 2021 08:28:43 PM PST
samiam#samiam-h-pc-2:~/projects/petit_ami$
The answers I have found so far talk about the use of localtime() (not localtime_r), or not having the timezone set, but you can see from above that was done.
This is on Ubuntu 20.04.
Thanks,
Scott Franco
San Jose, CA
Ok, playing with the date command:
samiam#samiam-h-pc-2:~/projects/petit_ami$ date
Sat 17 Jul 2021 08:28:43 PM PST
Is wrong, the time is 1:38pm (13:38), and the clock on the desktop shows the same. Trying to fix that:
samiam#samiam-h-pc-2:~/projects/petit_ami$ hwclock -r
hwclock: Cannot access the Hardware Clock via any known method.
hwclock: Use the --verbose option to see the details of our search for an access method.
Sat 17 Jul 2021 01:38:00 PM PST
samiam#samiam-h-pc-2:~/projects/petit_ami$ sudo date -s "july 17 2021 13:38"
Sat 17 Jul 2021 01:38:00 PM PST
samiam#samiam-h-pc-2:~/projects/petit_ami$ date
Sat 17 Jul 2021 08:38:42 PM PST
samiam#samiam-h-pc-2:~/projects/petit_ami$
oooooooo ok. Humm...
Clearly I am fighting with the time server, but not sure what is going on.
samiam#samiam-h-pc-2:~/projects/petit_ami$ timedatectl
Local time: Sat 2021-07-17 13:46:51 PDT
Universal time: Sat 2021-07-17 20:46:51 UTC
RTC time: Sat 2021-07-17 20:46:52
Time zone: America/Los_Angeles (PDT, -0700)
System clock synchronized: no
NTP service: n/a
RTC in local TZ: no
samiam#samiam-h-pc-2:~/projects/petit_ami$ ./test
gmt hour: 20 local hour: 20
samiam#samiam-h-pc-2:~/projects/petit_ami$
Requested by Steve:
samiam#samiam-h-pc-2:~/Desktop$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 39 Feb 23 21:41 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles
samiam#samiam-h-pc-2:~/Desktop$ wc /etc/localtime
8 86 2836 /etc/localtime
samiam#samiam-h-pc-2:~/projects/petit_ami$ echo $TZ
PST8PDT
samiam#samiam-h-pc-2:~/projects/petit_ami$ ./test
gmt hour: 21 local hour: 14
samiam#samiam-h-pc-2:~/projects/petit_ami$
samiam#samiam-h-pc-2:~/Desktop$ pa
samiam#samiam-h-pc-2:~/projects/petit_ami$ echo $TZ
America/Los_Angeles
samiam#samiam-h-pc-2:~/projects/petit_ami$ ./test
gmt hour: 21 local hour: 14
samiam#samiam-h-pc-2:~/projects/petit_ami$
This addresses the answer given by Steve:
samiam#samiam-h-pc-2:~/projects/petit_ami$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 39 Feb 23 13:41 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles
samiam#samiam-h-pc-2:~/projects/petit_ami$ echo $TZ
America/Los_Angeles
samiam#samiam-h-pc-2:~/projects/petit_ami$ ./test
gmt hour: 21 local hour: 14
samiam#samiam-h-pc-2:~/projects/petit_ami$ export TZ=""
samiam#samiam-h-pc-2:~/projects/petit_ami$ echo $TZ
samiam#samiam-h-pc-2:~/projects/petit_ami$ ./test
gmt hour: 21 local hour: 21
samiam#samiam-h-pc-2:~/projects/petit_ami$
Requested by KamilCuk:
samiam#samiam-h-pc-2:~/projects/petit_ami$ zdump -v -c 2019,2022 /etc/localtime
/etc/localtime -9223372036854775808 = NULL
/etc/localtime -9223372036854689408 = NULL
/etc/localtime Sun Mar 10 09:59:59 2019 UT = Sun Mar 10 01:59:59 2019 PST isdst=0 gmtoff=-28800
/etc/localtime Sun Mar 10 10:00:00 2019 UT = Sun Mar 10 03:00:00 2019 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 3 08:59:59 2019 UT = Sun Nov 3 01:59:59 2019 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 3 09:00:00 2019 UT = Sun Nov 3 01:00:00 2019 PST isdst=0 gmtoff=-28800
/etc/localtime Sun Mar 8 09:59:59 2020 UT = Sun Mar 8 01:59:59 2020 PST isdst=0 gmtoff=-28800
/etc/localtime Sun Mar 8 10:00:00 2020 UT = Sun Mar 8 03:00:00 2020 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 1 08:59:59 2020 UT = Sun Nov 1 01:59:59 2020 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 1 09:00:00 2020 UT = Sun Nov 1 01:00:00 2020 PST isdst=0 gmtoff=-28800
/etc/localtime Sun Mar 14 09:59:59 2021 UT = Sun Mar 14 01:59:59 2021 PST isdst=0 gmtoff=-28800
/etc/localtime Sun Mar 14 10:00:00 2021 UT = Sun Mar 14 03:00:00 2021 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 7 08:59:59 2021 UT = Sun Nov 7 01:59:59 2021 PDT isdst=1 gmtoff=-25200
/etc/localtime Sun Nov 7 09:00:00 2021 UT = Sun Nov 7 01:00:00 2021 PST isdst=0 gmtoff=-28800
/etc/localtime 9223372036854689407 = NULL
/etc/localtime 9223372036854775807 = NULL
samiam#samiam-h-pc-2:~/projects/petit_ami$ ls -l /etc/localtime
lrwxrwxrwx 1 root root 39 Feb 23 21:41 /etc/localtime -> /usr/share/zoneinfo/America/Los_Angeles
samiam#samiam-h-pc-2:~/projects/petit_ami$ ls -l /usr/share/zoneinfo/America/Los_Angeles
-rw-r--r-- 1 root root 2836 Jan 27 21:32 /usr/share/zoneinfo/America/Los_Angeles
samiam#samiam-h-pc-2:~/projects/petit_ami$
On a Linux system, there are normally two ways to set the time zone:
The file /etc/localtime is normally a symbolic link to one of the zoneinfo files from the tz database. For example, on my local machine (a Mac), it points to /var/db/timezone/zoneinfo/America/New_York, and on a Debian server I have access to in Seattle, it points to /usr/share/zoneinfo/America/Los_Angeles. In any case, /etc/localtime sets the machine's default time zone.
The environment variable $TZ can be used on a per-process basis to override the system default. $TZ can be used in two different ways: (a) it can contain the name of a file in the tz database, or (b) it can contain a string like PST8PDT that specifies the time zone directly.
When you call one of the localtime functions, it normally consults $TZ or /etc/localtime to find the information it needs to convert a UTC time to local time.
You have discovered that explicitly setting your $TZ variable fixes your problem. This suggests there may be something wrong with your system's copy of the tz database.
On your system, in its default mode, and although /etc/localtime seems to be pointing to the zonefile for America/Los_Angeles, both your test program and the system date command are acting like they're on UTC. Also the system date command is wrongly (doubly wrongly) reporting PST, neither the PDT you're on nor the UTC that it's actually reporting the hour of.
And yet when you set TZ to America/Los_Angeles, it also worked, suggesting that your tz file is fine.
All I can say at this point is that modern Linux distros (Ubuntu in particular) have been radically rewriting things that had been stable for years and that I thought I understood. I think I heard that ntpd had fallen victim to the borglike embrace of systemd, so perhaps the tz database has, too, and this is affecting your results in some bizarre way.
I tried following: https://www.aerospike.com/docs/operations/install/vagrant/mac/
and did following:
mkdir aerospike-vm
cd aerospike-vm
vagrant init aerospike/aerospike-ce
This creates Vagrantfile in the same directory.
Next I try:
vagrant up
Getting error:
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'aerospike/aerospike-ce' could not be found. Attempting to find and install...
default: Box Provider: virtualbox
default: Box Version: >= 0
The box 'aerospike/aerospike-ce' could not be found or
could not be accessed in the remote catalog. If this is a private
box on HashiCorp's Atlas, please verify you're logged in via
`vagrant login`. Also, please double-check the name. The expanded
URL and error message are shown below:
URL: ["https://atlas.hashicorp.com/aerospike/aerospike-ce"]
Error: The requested URL returned error: 404 Not Found
What is the proper procedure to install Aerospike on Mac?
Thanks
I recorded this few months ago along with two other videos in this set. See if this youtube video helps you out: https://www.youtube.com/watch?v=qm42c0juam4&list=PLGo1-Ya-AEQDa32hFggyB0yIIOldxUFwv&index=3
Here is the output from my run:
Administrators-MacBook-Pro-4:aerospike-vm piyush$ ls -al
total 8
drwxr-xr-x 4 piyush staff 128 Apr 9 2018 .
drwxr-xr-x+ 54 piyush staff 1728 Jan 18 10:56 ..
drwxr-xr-x 3 piyush staff 96 Apr 9 2018 .vagrant
-rw-r--r-- 1 piyush staff 3029 Apr 9 2018 Vagrantfile
Administrators-MacBook-Pro-4:aerospike-vm piyush$ mv Vagrantfile Vagrantfile_old
Administrators-MacBook-Pro-4:aerospike-vm piyush$ vagrant init aerospike/aerospike-ce
==> vagrant: A new version of Vagrant is available: 2.2.3!
==> vagrant: To upgrade visit: https://www.vagrantup.com/downloads.html
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.
Administrators-MacBook-Pro-4:aerospike-vm piyush$ ls -al
total 16
drwxr-xr-x 5 piyush staff 160 Jan 31 14:13 .
drwxr-xr-x+ 54 piyush staff 1728 Jan 18 10:56 ..
drwxr-xr-x 3 piyush staff 96 Apr 9 2018 .vagrant
-rw-r--r-- 1 piyush staff 3029 Jan 31 14:13 Vagrantfile
-rw-r--r-- 1 piyush staff 3029 Apr 9 2018 Vagrantfile_old
Administrators-MacBook-Pro-4:aerospike-vm piyush$
I'm trying to get tests working on my local dev machine Cloud SDK version is: 159.0.0
Everything I've read says that I should no change GOROOT so I'm not sure how to fix this.
$ /Users/bryan/google-cloud-sdk/platform/google_appengine/goroot/bin/goapp test
go: cannot find GOROOT directory: /tmp/go_sdk887571938/appengine/go_appengine/goroot
bryan#Bryans-MacBook Thu Jun 15 10:22:37 ~/go/src/skincarereview
$ go env
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/bryan/go/"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GO15VENDOREXPERIMENT="1"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fno-common"
CXX="clang++"
CGO_ENABLED="1"
bryan#Bryans-MacBook Thu Jun 15 10:22:57 ~/go/src/skincarereview
$ ls ~/google-cloud-sdk
total 408
drwxr-xr-x 30 bryan staff 1020 Jun 14 20:31 .install
-rw-r--r-- 1 bryan staff 980 Jun 14 20:30 LICENSE
-rw-r--r-- 1 bryan staff 673 Jun 14 20:30 README
-rw-r--r-- 1 bryan staff 162673 Jun 14 20:30 RELEASE_NOTES
-rw-r--r-- 1 bryan staff 8 Jun 14 20:30 VERSION
drwxr-xr-x 10 bryan staff 340 Jun 14 20:30 bin
-rw-r--r-- 1 bryan staff 2734 Jun 14 20:30 completion.bash.inc
-rw-r--r-- 1 bryan staff 2083 Jun 14 20:30 completion.zsh.inc
drwxr-xr-x 3 bryan staff 102 Jun 14 20:30 help
-rwxr-xr-x 1 bryan staff 1581 Jun 14 20:30 install.bat
-rwxr-xr-x 1 bryan staff 3471 Jun 14 20:30 install.sh
drwxr-xr-x 10 bryan staff 340 Jun 14 20:30 lib
-rw-r--r-- 1 bryan staff 308 Jun 14 20:30 path.bash.inc
-rw-r--r-- 1 bryan staff 1210 Jun 14 20:30 path.fish.inc
-rw-r--r-- 1 bryan staff 31 Jun 14 20:30 path.zsh.inc
drwxr-xr-x 6 bryan staff 204 Jun 14 20:30 platform
-rw-r--r-- 1 bryan staff 40 Jun 14 20:30 properties
bryan#Bryans-MacBook Thu Jun 15 10:24:22 ~/go/src/skincarereview
$ find / -name goroot 2>/dev/null
/Users/bryan/google-cloud-sdk/platform/google_appengine/goroot
bryan#Bryans-MacBook Thu Jun 15 10:28:43 ~/go/src/skincarereview
$ echo $PATH
/Users/bryan/google-cloud-sdk/bin:/Users/bryan/go/src/:/Users/bryan/google-cloud-sdk/platform/google_appengine/goroot/bin/:/Users/bryan/google-cloud-sdk/bin/:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/go/bin
Looking at main.go line 155, where I think the error is being thrown, I don't see where "goroot" is being set .
if fi, err := os.Stat(goroot); err != nil || !fi.IsDir() {
fmt.Fprintf(os.Stderr, "go: cannot find GOROOT directory: %v\n", goroot)
os.Exit(2)
}
You can try and follow the recommendation of this answer:
If your install is messed up beyond reason (happened to me once), just remove the cloud SDK and any references to it in your $PATH. Also completely uninstall the regular Go installation.
Then start from scratch. Install Go, unpack google-cloud-sdk, run installer (add to $PATH if needed), gcloud components install app-engine-go.
Voila.
As mentioned in that same answer, you don't set GOROOT anywhere, it is set for you.
You might want to read up on how go run/test works. The program basically builds into a temporary location and then runs, so that might be why it's complaining about your goroot.
This question could possibly help you: Golang: tests and working directory
I believe you are calling wrong goapp. You should be calling one that is directly in google_appengine folder as follows:
/Users/bryan/google-cloud-sdk/platform/google_appengine/goapp test
If you don't have goapp in google_appengine for some reason, I'll be quite surprised, but then following should work too. (Still the above is the correct way of calling it. goapp resolves appengine's goroot as a relative path from it's own location, so it's important where goapp itself is located.)
GOROOT=/Users/bryan/google-cloud-sdk/platform/google_appengine/goroot /Users/bryan/google-cloud-sdk/platform/google_appengine/goapp test