Anyway, here's the solution to getting picom running on login. Not much here, but it works.

.xsession

#!/bin/sh

# Make sure this is before the 'exec' command or it won't be sourced.
[ -f /etc/xprofile ] && . /etc/xprofile
[ -f ~/.xprofile ] && . ~/.xprofile

exec awesome

.xprofile

#!/bin/sh


# turn the bell off -- annoying
xset -b b off

# start picom
picom -b

The syntax for this is very similar to the update method, but only updates the dictionary if the key doesnt exist.

The help tells us:

dict.setdefault = setdefault(self, key, default=None, /)
    Insert key with a value of default if key is not in the dictionary.
    
    Return the value for key if key is in the dictionary, else default.

In practice it looks like.

mydict = {}
mydict.setdefault('first', 1)     # mydict == {'first': 1}
mydict.setdefault('first', '1st') # mydict == {'first': 1}

At work we have circled the wagons on Ansible for network automation. When it comes to automation the team that I am on is relatively inexperienced. Having a system that generates relatively familiar information is a definately in the plus column. Where it gets tricky is we are a service provider and our configs are long... I have been formulating a solution that should bring us home.

Solution

The configuration are broken out at first by "top level" configuration stanzas(groups, system, protocols, etc). For every one of the top level configuration files there is a ".d" directory created for smaller configuration pieces.

The result looks something similar to this:

.
└── templates
    ├── groups.d
    │   ├── groups-header.j2
    │   └── tacplus-servers.j2
    ├── groups.j2
    ├── system.d
    │   ├── system-header.j2
    │   └── tacplus-servers.j2
    └── system.j2

3 directories, 6 files

The tacplus-server.j2 template extends the groups-header.j2 file. This contains the outside block groups {} block in which we will be inserting configuration inside of for each group configuration that we generate.

# templates/groups.d/groups-header.j2

groups {
    {% block group_content %}{% endblock %}
}

As you can see I have defined a Jinja content block to to place the user defined groups configuration in.

Then in the tacplus configuration below we are extending group config and defining the content block.

# templates/groups.d/tacplus-server.j2

{% extends 'groups-header.j2' %}
{% block group_content %}
    replace:
    tacplus-servers {
        system {
            tacplus-server {
                <*> {
                    source-address {{ mgmt_ip }}
                    secret {{ vaulted_tacacs_secret }}
                    port 49
                }
            }
        }
    }
{% endblock %}

In the main groups.j2 template all we have to do is include any number of groups that we are defining.

# templates/groups.j2

{% include 'groups.d/tacplus-servers.j2' %}

The drawback to this approach is when you have more than one group defined. You will end up rendering configuration with multiple group {} blocks with one user defined groups configuration in it.

It will look funky, but Junos can figure it out.

The benfit from this methodology is we can define configuration in a service oriented fashion and do targeted changes to that service.

Lets fill out the rest of the templates so you can see what I mean. We will take the same approach on the system configurations.

# templates/system.d/system-header.j2

{% block system_content %}{% endblock %}

}

# templates/system.d/tacplus-servers.j2

{% block system_content %}
    tacplus-server {
{% for server in tacplus_servers %}
        {{ server }};
{% endfor %}
    }
{% endblock %}

# templates/system.j2

{% include 'system.d/tacplus-servers.j2' %}

So now lets define just the tacacs service in a file.

# /templates/service-tacacs.j2

{% include 'groups.d/tacplus-servers.j2' %}
{% include 'system.d/tacplus-servers.j2 %}

I know we can send the entire configuration to the router and Junos will decide what has changed and what hasn't, but we are still in a brown field environment and I would like to stay very tactical with our configuration changes. If we are not careful and we have a "cowboy config" out in the network we could end up isolting a router or not being able to manage it.

I hope this helps someone. I am currently restructuring our templates to implement these patterns.

You could employ a manager like Pyenv, Hatch, Pipenv, or Pyflow to take care of the heavy lifting, but that's another tool to learn and I a trying to simplify my worflow. What if we had management of the environments built right in our shell. That is when I ended up writing my own set of bash functions to manage my virtual environments. I am no bash guru, but they do work pretty nicely if I do say so myself.

I've had some thoughts on this since I started writing. Like using the projects directory name for the virtualenv name. This could save some typing. Maybe setting up PROMPT_COMMAND to point to a function that checks the $PYENV_HOME for an existing virtual environment and activates it automatically.

PYENV_HOME=$HOME/.venvs

# Init python venvs created in the .local/venvs dir
# activate <venv_name>
function chkarg() { if [ -z "$@" ]; then echo "${FUNCNAME[-1]} requires an venv name"; exit -1; else exit 0; fi }
function activate() {
    (chkarg $@)
    if [ -n "$VIRTUAL_ENV" ]; then
        deactivate
    fi
    source $PYENV_HOME/$@/bin/activate ;
}
function mkenv { (chkarg $@) && $(which python3) -m venv $PYENV_HOME/$@ ;}
function rmenv {
    (chkarg $@)
    if [ "$?" -ne 0 ]; then
        return -1
    fi
    ACTIVE=""
    if [ "$( basename $VIRTUAL_ENV)" == "$@" ]; then
        deactivate
    fi
    echo "removing $@"
    $(which rm) -fr $PYENV_HOME/$@ ;
}

#function rmenv { (chkarg $@) && echo "removing $@";}
function lsenv {
    ACTIVE=""
    if [ -n "$VIRTUAL_ENV" ]; then
        ACTIVE=$(basename $VIRTUAL_ENV)
    fi
    for d in $(ls -d $PYENV_HOME/* 2> /dev/null); do
        VENV_NAME=$(basename $d)
        if [ "$VENV_NAME" = "$ACTIVE" ]; then
            echo "* $VENV_NAME";
        else
            echo "  $VENV_NAME"
        fi
    done ;
}

os pathlib

Finding The Path Of Your Script

os module

base_dir = os.path.dirname(__file__)

pathlib

base_dir = pathlib.Path(__file__).parent

The Users Director

os module

# this can change if you change directories in the script
user_dir = os.getcwd()

pathlib module

# this can change if you change directories in the script
user_dir = pathlib.Path.cwd()

All Exceptions are derived from BaseException

Concrete Exceptions

In Python, "concrete exceptions" refer to specific, built-in exception types that are raised by the interpreter or standard library functions in response to various error conditions. These contrast with more general exception types (like Exception itself) or user-defined exceptions.

Examples:

• TypeError
  • Class methods or functions will raise a TypeError when called without the correct amount of positional arguments.

"hello" + 5 # Raises TypeError; string and int types cannot be added

import math
math.pow(2) # Raises TypeError

• ValueError

int("abc") # Raises ValueError for incompatible value being passed to int()

• IndexError

my_list = [1,2,3]
my_list[5] # Raises IndexError

• KeyError

my_dict = {'a': 1}
my_dict['b'] # Raises KeyError

• NameError

print(not_defined_variable) # Raises NameError

• ZeroDivisionError

10 / 0 # Raises ZeroDivisionError

• FileNotFoundError

with open('non_existent_file.txt', 'r') as fp: # Raises FileNotFoundError
    pass

• AttributeError

my_str = "this is some text"
my_str.non_existent_method() # Raises AttributeError

• ImportError

import non_existent_module # Raises ImportError

If you are just running an online store and the site is going to host your cool shop then set up an A record like this.

• Type: A
• Name: @
• Data / IP: 23.227.38.65
• TTL: 1 hour / 3600 seconds

If you have a site and you just want a small store to sell a cool widget you started making then you will need to set up a CNAME record for a sub-domain. eg. mycoolsite.com -> shop.mycoolsite.com

• Type: CNAME
• Name: shop / store / dealers choice
• Data: shops.myshopify.com
• TTL: 1 hour / 3600 seconds

Shopify domain setup

E-mail Setup

The sender email address is the one that will show up in the From field of the recipients email.

Steps:

1. From your Shopify admin, go to Settings > Notifications
2. In the Sender email section, enter your email address.
3. Click Save.

Add CNAME records to your third-party domain

You can help to ensure that your email messages reach your customers by adding CNAME records to your third-party domain to connect it to the Shopify SPF and DKIM records. You don't need to add any IP addresses to your domain - the CNAME records are sufficient for authentication.

To add CNAME records to your domain, you need to have the following information:

your login information for your third-party domain provider account associated with your sender email your sender email, which is the email address that you use to communicate with your customers

Steps:

1. From your Shopify admin, go to Settings > Notifications.
2. In the Sender email section, click authenticate your domain.
3. Follow the instructions to enter the new CNAME records into your third-party domain manager.

Changes can take up to 48 hours to complete. If the domain verification fails, then verify that the DNS records that you entered into your third-party domain provider match the records that were provided in your Shopify admin.

If you need help to add a CNAME to your domain, then contact your domain provider.

Shopify email setup