Bootstraps

Welcome to bootstrap for your dev ops and linux adventures.

" The phrase “pull yourself up by your bootstraps” originated shortly before the turn of the 20th century. It’s attributed to a late-1800s physics schoolbook that contained the example question “Why can not a man lift himself by pulling up on his bootstraps?” "sauce

" People understood the expression "pulling yourself up by your bootstraps" to mean "attempting to do something absurd" until roughly the 1920s, at which point it started to evolve toward the current understanding: to do something without any outside help.

I think across all people, it's universally true that there are things that you benefit from that you did not contribute to. There are things that you benefit from that you did not build; there are things that you benefit from that you did not make. You benefit from the roads that are built, from people that have helped you along the way, from the mentors that you accidentally found yourself in the same classroom with.

This isn't to say that hard work doesn't matter; it's just to say that it's not the only thing. No one pulls themselves up by their bootstraps. No one can. " sauce Good luck!

This isn't to say that hard work doesn't matter; it's just to say that it's not the only thing. No one pulls themselves up by their bootstraps. No one can. " sauce

Let these bootstraps be a helping hand to pull on. Built on top of millions of lines of code and millions of iterations by millions of people. These scripts operate on another plane of complexity and thus power. With a single line you can do what people have spent lifetimes working on.

And if that's not enough confusion the project has been renamed internally to no straps aka nos.

dashboard.netmaker.nos.endpoint.ca retool.nos.endpoint.ca

cli: nos install cat

Oth

Oath (optional)

I __ Will Commit useful working scripts!

I __ will try to keep undue complexity down. (reducing obscurity can improve security)

I __ will document my scripts to make them approachable by a new admin.

Index

at each level we divide between development mess and working productions prod

First we divide on base os: alpine or debian or common_posix

Other directories may then be created as required, try and keep the structure clean.

• alpine : all scripts for bootstrapping alpine systems (note this meets different requirements** than the tinycloud project)
  • ocmgm : the Open Closed Mesh Grid Map system's initialization scripts
    • secure : (should we add secure to the acronym to make it socmgm), soc is kind of a nice name secure open close
    • open : the systems is open source/ the open(ed) server(s) allows secure connections into the system
    • closed : the internal systems is private and closed off from external access (reduced/limited attack vectors)
    • mesh : the closed systems communicate internally (openly) within the local mesh
    • grid : the closed systems communicate securely even across internet bridges using a secure virtual private network This also allows for centralized management of the distributed system in combination with Map
    • map : all servers call home to the centrally managed Map server
• debian : all scripts for bootstrapping debian systems

** the main difference is... <--TODO-->

HAPI

HAPI is a Virtual machine 'Hosts' 'Apps'/software ,on infrastructure 'Platforms' using some api 'Integrations'

hosts<<->>apps<<->>integration 
            \platforms/    

host may have many apps
apps may have many hosts
apps may have many integrations
integrations may have many apps
platforms have an integration
hosts have a platform 



schema 

hosts(id,name, platform_id,)

apps(id, name, repo, root_sh, domains[], acls[], sins[], apis[])

platforms(id, integration_id)
host_integration ??

integrations(id, name, )

//deployment
app_host(app_is, host_id)

// we may not need this since APIs are linked in the apps.. probably by name
//app_integration(app_id, integration_id)

//hdapi ? nice name but i almost like hapi more does it make sense to get rid of the D to and put an array of apps in 
// the hosts tables  (HAPI Deployments)





Here are some possible tables and columns for a HAPI system:

Hosts

    id (primary key)
    name (unique)
    description
    status (active, inactive, etc.)

Apps

    id (primary key)
    name (unique)
    description
    status (active, inactive, etc.)
    host_id (foreign key to Hosts table)

Integrations

    id (primary key)
    name (unique)
    description
    status (active, inactive, etc.)

Platforms

    id (primary key)
    name (unique)
    description
    status (active, inactive, etc.)
    integration_id (foreign key to Integrations table)

App_Integrations (junction table for many-to-many relationship between Apps and Integrations)

    app_id (foreign key to Apps table)
    integration_id (foreign key to Integrations table)

Host_Platforms (junction table for one-to-many relationship between Hosts and Platforms)

    host_id (foreign key to Hosts table)
    platform_id (foreign key to Platforms table)

Naming your scripts

Use overly long verbose names tab completion is a thing.

Pay close attention to the first and second word you use it determines order

If scripts are met for a common purpose try to name them so they appear in the order of execution next to each other when sorted alphabeticaly.

If the purpose is rare put them in a verbosely named directory.

keywords for scrip naming

• install
• start
• stop -
• status - check if something is running usually a service
• remove - uninstall and delete something
• test - test something and tell you if it's messed up
• debug - debug an application use rest of name to
• ??? - read the code

# one way of naming this might be the fallowing due to it placing steps in order of execution
#ABCDEFGHIJKLMNOPQRSTUVWXYZ
# abcdefg get
# h help
# i install
# jklmno open
# pq quit
# r remove
# s start
# s status
# s stop
# t test
# uvwxyz

giisajd