From ffede62f039d56a2cbedee7a5bb61764661753e8 Mon Sep 17 00:00:00 2001 From: Luke Smith Date: Thu, 1 Jul 2021 07:20:36 -0400 Subject: rss updates --- rss.xml | 388 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 388 insertions(+) (limited to 'rss.xml') diff --git a/rss.xml b/rss.xml index d621a10..edd03b9 100644 --- a/rss.xml +++ b/rss.xml @@ -15,6 +15,394 @@ + +Hosting Your Own Git Repositories – LandChad.net +https://lukesmith.xyz/git.html +https://lukesmith.xyz/git.html +Thu, 01 Jul 2021 07:19:51 -0400 +

Hosting Your Own Git Repositories

+ +
+ +

+ Once you have your own VPS or other Internet-available server, you can + start hosting your own git repositories. The goal of this tutorial is + for you to go from

+ 
git clone github.com/...
+

to

+ 
git clone YourLandChadDomainName.xyz/...
+

+ so you can cultivate your own homegrown, grass-fed code, rather than + relying on a centralized proprietary service like GitHub. +

+

Installing git

+

+ You most likely already have it installed on your server, but if not, + run:

+ 
apt install git
+

+ We don't need any additional software, git itself ships + with everything needed to host a remote repository! +

+

Creating bare repositories

+

+ For each repository you want to host, you will need to manually create + what's called a "bare" repository on your server. These hold all the + commits and any other git data needed for your repository, but without + an expanded "index" in which you can just browse all the files of a + certain commit in the file system. +

+

+ These repositories need to be owned by the git user, and + you should probably pick a directory where you will store them all. One + sane choice is under /srv/git/, and we will use this as the + example directory for the rest of the tutorial, but any other path will + do as well. +

+

Become the git user and create the directory

+

+ If you're logged in to your server as root and have git + installed, you can become the git user by executing +

+ 
su git
+

+ Now navigate to/create your desired directory, for example +

+ 
cd /srv
+mkdir git
+

Create the repo

+

+ Now you can create the bare repository with +

+ 
git init --bare my-repo.git
+

+ By convention, bare repository names end with ".git". +

+

+ Repeat the above command for any other repositories you want to host. +

+

Syncing local repositories with your server

+

Set up SSH login for the git user

+

+ You will need to be able to login remotely via ssh as the + git user we've used before. To do this, you will either + need to set up a password for the git user by running + passwd git, + or copy your public SSH key from your local machine to + /home/git/.ssh/authorized_keys. + See the SSH keys instructional for details + (just log in as git instead of root). +

+

Syncing a new repository with your server

+

+ If you've just created a new repository on your local machine, you will + need to tell git where the remote repository is to be able + to sync with it (using commands like git push or + git pull). We do this by defining a "remote" for your + repository. +

+

+ A remote is just a named URL remembered in your repo's configuration. So + we need a name and a URL. By convention, the "main" remote is called + "origin". The URL has the format user@host:path, where: +

+
    +
  • + user is git, the git user + we've already worked with before. +
    • +
  • + host is your domain name. + Alternatively you could even use your server's raw IP address. +
    • +
  • + path is the absolute path to the repository on the + server, in our example /srv/git/my-repo.git +
    • +
+

+

+ So, to create a new remote, run: +

+ 
git remote add origin git@yourdomain.xyz:/srv/git/my-repo.git
+

+ Now you'll be able to run git push origin master to push + your commits or git pull origin to pull from the remote. +

+

Syncing an existing repository

+

+ If you've already set up your local repository to sync with a service + like GitHub it probably already has a remote called "origin". You can + see your repo's remotes with: +

+ 
git remote -v
+

+ You can follow the above instructions, substituting an arbitrary other + name other than "origin" to create a differently named remote, e.g. +

+ 
git remote add vps git@...
+

+ Now you'll be able to push/pull with git push vps master + and git pull vps, respectively. +

+

+ Or, to completely sever ties with your centralized git provider, first + remove the original origin with: + git remote remove origin + and then follow the instructions as above. +

+

Contribution

+ +
+ +]]> + + + + +Requiring Passwords for Webpages (HTTP Authentication) – LandChad.net +https://lukesmith.xyz/auth.html +https://lukesmith.xyz/auth.html +Thu, 01 Jul 2021 07:19:27 -0400 +

Requiring Passwords for Webpages

+ +
+ access control with nginx +

HTTP basic authentication will allow you to secure parts (or all) of your website with a username and password without the trouble of PHP or Javascript. + This will work with any Nginx server. +

+

Installation

+

We will be using the command htpasswd to make username and password pairs.

+ 
apt install apache2-utils
+ +

+ Now think of a username and password and remember them. +

+ 
htpasswd -c /etc/nginx/myusers username
+ +

+ Type out your password twice to confirm. You can do this as many times as you'd like. +

+

Check out user name password pairs (the password will be securely hashed):

+ 
cat /etc/nginx/myusers
+

Nginx Config and Auth Basic

+

+ From here, we are going to edit our websites config file in /etc/nginx/sites-enabled. + Have in mind which folder you'd like to secure. Add something like this: +

+ 
server {
+    #...
+    location /secret-folder  {
+        auth_basic "What's the Password?" ;
+        auth_basic_user_file /etc/nginx/myusers ;
+    }
+    #...
+}
+ +

If you'd like to do the opposite, such as making the entire site private except for a public section, do this:

+ 
server {
+    #...
+    auth_basic "What's the Password?" ;
+    auth_basic_user_file /etc/nginx/myusers ;
+    location /public/ {
+        #...
+        auth_basic off ;
+    }
+    #...
+}
+

IP Addresses

+

If passwords aren't enough we can ban an ip or accept one.

+ 
location /api {
+    #...
+    allow 192.168.1.23:8080 ;
+    deny 127.0.0.1 ;
+}
+

If you want to check both a username and password with an ip address, use the satisfy directive.

+ 
location /api {
+    #...
+    satify all ;
+    allow 192.168.1.23:8080 ;
+    deny 127.0.0.1 ;
+    auth_basic "What's the Password?" ;
+    auth_basic_user_file /etc/nginx/myusers ;
+}
+

Complete Example

+ 
http {
+    server {
+        listen 80;
+        root /var/www/website ;
+        #...
+        location /secret-folder {
+            satisfy all ;
+            allow 192.168.1.3/24;
+            deny 127.0.0.1 ;
+            auth_basic "What's the Password?" ;
+            auth_basic_user_file /etc/nginx/myusers ;
+        }
+    }
+}
+

+ Now check your configuration with nginx -t +

+

Reload nginx and you're good to go!

+ Contributor - tomfasano.xyz +
+ +]]> + + + + +Cronjobs – LandChad.net +https://lukesmith.xyz/cron.html +https://lukesmith.xyz/cron.html +Thu, 01 Jul 2021 07:19:04 -0400 +

Using Cronjobs to run scheduled tasks

+ +
+

+ Cron is a service that lets you run scheduled tasks. These tasks are called cronjobs. If you have already followed the initial course you will have already used cron when you set up certbot. +

+

What tasks would I want to schedule?

+

+ You can schedule anything! Some examples of what you might have done already include: +

    +
  • updatedb to update your locate database
    • +
  • certbot to update renewing of your https certs
    • +
+ Some tasks that you might want to schedule may include: +
    +
  • Package updates - if you really just want to leave your server alone you can automated updating packages on your server
    • +
  • Backups - you may want to backup certain files every day and some every week, this is possible with cron
    • +
+

+ And many more, anything you can do can be turned into a cronjob. +

+

Basic Cronjobs

+

+ This the preferred method for personal tasks and scripts, it's also the easiest to get started with. Run the command crontab -e to access your users crontab +

+

+ Once you have figured out the command you want to run you need to figure out how often you want to run it and when. I am going to schedule my system updates once a week on at 3:30 AM on a Monday. +

+

+ We now have to convert this time (Every Monday at 3:30 AM) into a cron time. Cron uses a simple but effective way of scheduling when to run things. +

+

+ Crontab expressions look like this * * * * * command-to-run + The five elements before the command tell when the command is supposed to be run automatically. +

+ So for our Monday at 3:30AM job we would do the following: +

+ 

 .---------------- minute (0 - 59)
+ | .------------- hour (0 - 23)
+ | | .---------- day of month (1 - 31)
+ | | | .------- month (1 - 12
+ | | | | .---- day of week (0 - 6)
+ | | | | |
+ * * * * *
+30 3 * * 1 apt -y update && apt -y dist-upgrade
+

Some notes

+
    +
  • On the day of the week option, Sunday is 0 and counting up from there, Saturday will be 6.
    • +
  • * designates "everything". Our command above has a * in the day of month and month columns. This means it will run regardless of the day of the month or month.
    • +
  • The hour option uses 24 hour time. 3 = 3AM, while use 15 for 3PM.
    • +
+

More examples

+

+ Let's add another job, our backup job (for the purposes of this our backup command is just called backup) We want to run backup Every evening at 11PM, once we work out the timings for this we can add the to the same file as the above by running crontab -e This would mean our full crontab would look like this: + 

0 23 * * * backup
+

Consecutive times

+

+ Suppose we want a command to run every weekday. + We know we can put 1 (Monday), but we can also use 1-5 + to signify from day 1 (Monday) to day 5 (Friday). +

+ 
0 6 * * 1-5 echo "Wakey, wakey, wagie!" >> /home/wagie/alarm
+

The above echo command runs every Monday through Friday at 6:00AM.

+

Non-consecutive times

+

+ We can also randomly specify non-consecutive arguments with a comma. + Suppose you have a script you want to run at the midday of the 1st, 15th, and 20th day of every month. + You can specify that my putting 1,15,20 for the day of the month argument: +

+ 
0 12 1,15,20 * * /usr/bin/pay_bills_script
+

"Every X minutes/days/months"

+

We can also easily run a command very several minutes or months, without specifying the specific times: +

+ 
*/15 * * * * updatedb
+

+ This cronjob will run the updatedb command every 15 minutes. +

+

Beware of this Rookie Mistake Though...

+

+ Suppose you want to run a script once every other month. + You might be tempted write this: +

+ 
* * * */2 *
+

+ That might feel right, but this script will be running once every minute during that every other month. + You should specify the first two arguments, because with * it will be running every minute and hour! +

+ 
0 0 1 */2 *
+

This makes the command run only at 0:00 (12:00AM) on the first day of every two months, which is what we really want.

+

+ Consult the website crontab.guru for an intuitive and interactive tester of cronjobs. +

+

User vs. Root Cronjobs

+

+ It is important to note that user accounts all have different cronjobs. + If you have a user account chad and edit his crontab with crontab -e, + the commands you add will be run as the chad user, not root or anyone else. +

+

+ Bear in mind that if you need root access to run a particular command, + you will usually want to add it as root. +

+

System-wide cron directories

+

+ crontab -e is the typical interface for adding cronjobs, but it's important to at least know that system-wide jobs are often stored in the file directory. + Some programs which need cronjobs will automatically install them in the following way. +

+

+ Run the command ls /etc/cron* you should see a list of directories and there contents. The directories should be something like the below +

    +
  • /etc/cron.d This is a crontab like the ones that you create with crontab -e
    • +
  • /etc/cron.hourly
    • +
  • /etc/cron.daily
    • +
  • /etc/cron.weekly
    • +
  • /etc/cron.monthly
    • +
+

+ The directories cron.{hourly,daily,weekly,monthly} are where you can put scripts to run at those times. You don't put normal cron entries here. I prefer to use these directories for system wide jobs that don't relate to an individual user. +

+

Contribution

+ +
+ +]]> + + + Mirror your site over tor https://lukesmith.xyz/tor.html -- cgit v1.2.3