Алина Масло

GoLevelDB - вовсе не на чистом Go. И это вовсе не SQL, а key-value.

Если вам БД типа key-value, написанную на чистом Go, то это BoltDB. Отличнейшая вещь для использования как emedded.

Если вам timeseries-БД на Go - это InfluxDB

Прочие см. тут:
https://github.com/avelino/awesome-go#database

Центральный показатель для бизнеса, а следовательно и руководителей, как людей представляющих интересы этого самого бизнеса - это коэффициент возврата инвестиций (ROI). Соответственно, сотрудник должен приносить компании больше денег, чем потребляет. Естественно, что чем выше разрыв между затратами и прибылью, тем лучше, поэтому фонд оплаты труда руководитель должен держать на том минимальном уровне, который гарантирует бесперебойную работу сотрудников. Один из факторов этой бесперебойности - низкая текучка. Сотрудников терять нежелательно. И чем ценнее для компании сотрудник, чем более он профессионален и/или чем больше на него завязано, тем дороже обходится его потеря. Натурально в деньгах. Придётся затратить больше, чем обычно, денег на поддержание работы без него. Придётся затратить деньги и время (те же деньги) на поиск, найм, введение в работу, возможно, обучение нового сотрудника. При этом он может оказаться совсем неподходящих и цикл придётся повторить. Или может оказаться просто хуже прошлого и эффективность отдела снизится. Поэтому, когда сотрудник приходит просить прибавку, руководитель оценивает может ли этот сотрудник уйти или только блефует, насколько легко его будет заменить, какой урон компании будет нанесён его уходом. Потом руководитель оценивает стоимость расширения ФОТ - есть ли резервы, какой сейчас ROI, будет ли больший ROI от реинвестиции этих средств во что-то другое? Если уход сотрудника будет стоить меньше, чем увеличение ФОТа, сотруднику откажут.

Естественно, всё описанное справедливо для случая, когда руководитель - профессиональный менеджер. А то часто на месте руководителя сидит человек руководствующийся эмоциями и мутными соображениями вычитанными в сомнительной бизнес-литературе.

Из этого вывод, стратегия проста - увеличивайте собственный профессиональный уровень на столько, чтобы свободно менять компанию, как только вас что-то перестало устраивать.

Если всё делать по стандартному фэн-шую, то никаких отличий от обыкновенных OpenSSL туториалов то и нет:

0. Если нет уже готового CA (Certificate Authority), то генерируем новый: ecdsa.GenerateKey() + x509.CreateCertificate() (self-signed).

1. Генерируем приватный ключ PK (Private Key) для своего сертификата: ecdsa.GenerateKey().

2. Генерим запрос на создание сертификата CSR (Certificate Signing Request): x509.CreateCertificateRequest(). В качесте CN (Common Name) указываем тот адрес, по которому будем стучаться к приложению. Если таких адресов предполагается несколько, то используем SAN расширение в шаблоне сертификата.

3. Берем CA и выпускаем себе сертификат по сгенерированному CSR: x509.CreateCertificate().

4. Используем сертификат для TLS: http.ServeTLS().

Приватный ключ и сертификат (и свой, и CA) сохраняем в любую желаемую директорию в файловой системе. Права к приватным ключам при этом выставляем 0600. Если это дело всё разовое, то можно и во временную директорию (os.TempDir()), чтобы не мусорить.

Если это только чтобы поиграться, и не предполагается выстраивание своей PKI (Public Key Infrastructure), то можно и не париться с CA/CSR, а сразу выпускать self-signed сертификат с нужными Вам CN/SAN. То есть, остается только нулевой шаг.

Если у нас приложение пырится во внешний мир не "голым", а прикрыто каким-то проксирующим сервером (например, Nginx), что, в принципе, есть даже рекомендуемой практикой, то сертификат можно подключать для нашего хоста прямо там, а приложение оставить себе без TLS. В этом случае Nginx будет расшифровывать трафик у себя и в приложение пробрасывать уже незашифрованный трафик. Подобное называется терминацией TLS.
Если же мы хотим, чтобы между прокси-сервером и нашим приложением продолжал ходить зашифрованный трафик, то прокси-серверу нужно в настройках скормить наш CA сертификат, либо отключить проверку CA.

https://www.gonum.org/

https://codepen.io/meylisday/pen/LQJmaW

import (
    "fmt"
    "os"
    "os/user"
    "syscall"
)
func fileUserName(filename string) (username string, err error) {
	stat, err := os.Stat(filename)
	if os.IsNotExist(err) {
		return
	}
	uid := stat.Sys().(*syscall.Stat_t).Uid
	User, _ := user.LookupId(fmt.Sprint(uid))
	username = User.Username
	return
}

import (
    "fmt"
    "os"
    "os/user"
    "syscall"
)
func printUserName() {
var file, _ = os.Open("/etc/fstab")
var fi, _ = file.Stat() //Получаем FileInfo файла
var uid = fmt.Sprint(fi.Sys().(*syscall.Stat_t).Uid)
var User, _ = user.LookupId(uid)
fmt.Printf("%v\n", User.Username)
}

Не уверен что правильно понимаю суть вопроса, но мне кажется что список юникс пользователей должен находиться где-то примерно тут /etc/passwd. При запросе на регистрацию читаете данный файл, если юзер уже существует, то возвращаете ошибку, если юзверя нет, то выполняете useradd через exec.Command

подписываешься
https://golangweekly.com/issues

шуршишь что приходит, найдешь крутых

следить только утомляет ))

мульти домены - это CORS? Тогда все просто. Я днями решал. И на net/http, потом на echo.

// CORS restricted
		e.Use(middleware.CORSWithConfig(middleware.CORSConfig{
			AllowOrigins:     makeStrArray(cfg.Functional.CORS.AllowOrigins),
			AllowMethods:     makeStrArray(cfg.Functional.CORS.AllowMethods),
			AllowHeaders:     makeStrArray(cfg.Functional.CORS.AllowHeaders),
			AllowCredentials: true,
		}))