Tag Cloud
Currently Reading
Latest Book Reviews
- Certified Kubernetes Application Developer (CKAD) Study Guide, 2nd Edition Posted on January 11, 2025
- Rancher Deep Dive Posted on March 31, 2023
- Leveraging Kustomize for Kubernetes Manifests Posted on March 24, 2023
- Automating Workflows with GitHub Actions Posted on October 13, 2022
- Deep-Dive Terraform on Azure Posted on August 30, 2022 All Book Reviews
Latest Posts
- 389 Directory Server GUI with Cockpit Posted on March 28, 2021
- Exclude comments and empty lines from file Posted on May 24, 2020
- Running Ubuntu Server on an Intel NUC 10th i7 Posted on March 2, 2020
- Send Email from a Shell Script Using Gmail’s SMTP Posted on June 10, 2019
- Configuring Postfix to use Gmail Posted on May 25, 2019
March 28, 2021
389 Directory Server GUI with Cockpit
by Alpha01
So I have a 389 Directory Server up and running. The next step to ease administration was to find a GUI. My first logical approach was to use Apache Studio, however I’m trying to the keep number of non ARM applications on my shiny Apple M1 MacBook Pro to an absolute minimum, so I opted to not install Apache Studio. At least not yet. Luckily, I learned that RedHat has a Webmin equivalent called Cockpit that comes with built-in support for 389 Directory Server Management.
The Cockpit application was already installed on my base RHEL 8 system, I simply just copied over my fullchain Let’s Encrypt SSL certificate to /etc/cockpit/ws-certs.d/ssl.cert
and restart the service.
systemctl restart cockpit
Then it was just a matter of updating firewalld
firewall-cmd --add-port=9090/tcp
firewall-cmd --permanent --add-port=9090/tcp
firewall-cmd --reload
The Cockpit application runs by default on port :9090
389-directoryserver
rhel
cockpit
]
May 24, 2020
Exclude comments and empty lines from file
by Alpha01
Every so often theirs the need to view a configuration (usually a large one), and you want an easy way to exclude all comments and empty lines:
egrep -v '^(#|$)' your-config-file.cfg
bash
]
March 2, 2020
Running Ubuntu Server on an Intel NUC 10th i7
by Alpha01
Late last year, I purchased a secondary Intel NUC 8th i3 for my homelab. My main goal was to use this secondary NUC primarily to learn Mesos and Kubernetes more in depth. Little that I knew that the dual core i3 on the NUC was not truly powerful enough to run a simple ten node DC/OS cluster, let alone another Kubernetes cluster on the same machine. So I decided to wait until the new i7 10th generation Intel NUCs were released, so I can upgrade.
The upgrade itself was not as easy as I first imagine. Both the RAM and hard drive were swapped from the old 8th gen NUC to the new 10th gen NUC. Ubuntu started up successfully, and all the memory was properly recognized on the new machine, however networking was not working. My first thought was that since now Linux was running on a new hardware, I needed to remove the old NIC’s udev configuration. I soon realized that apparently in the post systemd world, we no longer need to do this. After a quick Google search, I found a Reddit post that outline my exact problem. https://www.reddit.com/r/intelnuc/comments/eox6k1/caution_new_frost_canyon_nucs_have_an_integrated/
I was shocked to learn that the new 10th gen NUC’s network card is so new that it doesn’t even have its driver on the latest Ubuntu Server LTS! Luckily compiling and loading the newer e1000e driver was a really easy task. The only caveat was that I had to go into the UEFI Bios and disable secure boot and allow 3rd party modules, otherwise the new kernel module would fail to load.
After a few hours of usage, performance is completely night a day. The new 10th gen i7 hex core processor completely blows 8th gen i3 dual core, out of the water.
Tags: [ubuntu
]
June 10, 2019
Send Email from a Shell Script Using Gmail’s SMTP
by Alpha01
In my previous post, I enabled my local mail server to relay all outgoing mail to Google’s SMTP servers. However if you want to completely bypass using any sort of MTA, then you will only need to configure your Mail User Agent client to use Gmail STMP settings directly.
In Linux, I’ve always used the mailx utility to send out email messages from the command line or from a shell script. By default, mailx uses the local mail server to send out messages, but configuring it to use a custom SMTP server is extremely easy.
Inside a shell script configuration would look like this:
to="[email protected]"
from="[email protected]"
email_config="
-S smtp-use-starttls \
-S ssl-verify=ignore \
-S smtp-auth=login \
-S smtp=smtp://smtp.gmail.com:587 \
-S from=$from \
-S [email protected] \
-S smtp-auth-password=ULTRASECUREPASSWORDHERE \
-S ssl-verify=ignore \
-S nss-config-dir=/etc/pki/nssdb \
$to"
echo "Test email from mailx" | mail -s "TEST" $email_config
To have the mail settings configured to be used by mailx from the command line simply set your settings in ~/.mail.rc
set smtp-use-starttls
set ssl-verify=ignore
set smtp=smtp://smtp.gmail.com:587
set smtp-auth=login
set smtp-auth-user=[email protected]
set smtp-auth-password=ULTRASECUREPASSWORDHERE
set from="[email protected]"
set nss-config-dir=/etc/pki/nssdb
Resources
Tags: [google
smtp
]
May 25, 2019
Configuring Postfix to use Gmail
by Alpha01
Configuring Postfix to use Gmail as the outgoing SMTP relay endpoint is a relatively simple process. I’m my case, I’m not using an @gmail.com account. Rather, since all of my domains use G Suite, I’ve created a special dedicated email account that I’ll be using to send out email from.
Before starting configuring Postfix, it is important that you enable “Less secure app access” on the Gmail account that you will be configuring to send outgoing messages.
I’m using CentOS 7.x as my mail server OS. These were the steps I used to configure Postfix.
1). Install necessary packages:
yum install postfix mailx cyrus-sasl cyrus-sasl-plain
2). Create /etc/postfix/sasl_passwd
file with the your authentication credentials:
[smtp.gmail.com]:587 [email protected]:mypassword
3). Update file permissions to lockdown access to our newly created authentication config file:
chmod 600 /etc/postfix/sasl_passwd
4). Use the postmap
command to compile and hash the contents of sasl_passwd:
postmap /etc/postfix/sasl_passwd
5). Update /etc/postfix/main.cf
relayhost = [smtp.gmail.com]:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_security_options =
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_tls_CAfile = /etc/ssl/certs/ca-bundle.crt
6). Finally, enable and restart postfix:
systemctl enable postfix
systemctl restart postfix
Lastly, although it’s not needed to get a working Postfix to Gmail STMP config working. I would recommend enabling outgoing throttling. Otherwise Google might temporarily suspend your account from sending messages!
Additional /etc/postfix/main.cf
updates:
smtp_destination_concurrency_limit = 2
smtp_destination_rate_delay = 10s
smtp_extra_recipient_limit = 5
In my case, I configured Postfix to only handle two concurrent relay connections, wait at least 10 seconds to send out the email and set the recipient limit to 5 (per queue message session).
NOTE: As I mentioned, since I’m not using an @gmail.com, I had to add an SPF DNS record so that the outgoing emails pass all of Google’s spam tests.
DNS txt record:
v=spf1 include:_spf.google.com ~all
Example received email header that was sent from the newly Postfix to Gmail smtp configuration:
To conclude, it is import to remember that this Postfix configuration will overwrite whatever From
source set by your mail user agent (as the above email header image demonstrates).
Resources
- https://www.howtoforge.com/tutorial/configure-postfix-to-use-gmail-as-a-mail-relay
- https://wiki.deimos.fr/Postfix:_limit_outgoing_mail_throttling.html
postfix
google
]