Steps to deploy OpenCheckin to PythonAnywhere and confirm the deployment:

It is encouraged that you pause the video at any time during setup and configuration so that you can follow along more easily, or watch to the end first and then begin.

To begin, create your own free PythonAnywhere account at pythonanywhere.com.  Email confirmation will be required with your own email provider.  After logging in with your account, follow these steps:

Step 1: Clone software into PythonAnywhere
    1: Click on the Dashboard tab in PythonAnywhere
    2: Open up a new Bash console.
    3: Confirm current working directory by using the "pwd" command.
    4: Press the enter key to run the command.
    5: Working environment should be /home/yourusername.
    6: Paste the code "git clone https://github.com/ezst036/OpenCheckIn" into the console.  Press enter.
    7: Keep Bash console open, do not close.  For free accounts, PythonAnywhere only allows two Bash consoles.  You can re-use existing Bash consoles by using another browser tab to access other parts of the PythonAnywhere administrator site.

Step 2: Create virtual working environment and install dependencies
    1: Paste the command "mkvirtualenv --python=/usr/bin/python3.9 myenv"
    2: Notice that the Bash window changed and now says "(myenv)".  This means that the virtual environment is active.  Myenv should only be used for evaluation or testing purposes.
    3: Paste the command "pip install -r /home/yourusername/OpenCheckIn/requirements.txt".  Pip is a built in program for use with Django that will find all of the requirements you need to get OpenCheckIn working properly.  The included requirements document tells Pip where to begin and there will be a lot to do in this first install.  It should take 4-5 minutes to complete.
    4: At the top right of the screen, open the menu and right click the option for Dashboard.  Open in a new tab.

Step 3: Add a new web app
    1: Click on the Web tab in PythonAnywhere
    2: Click "Add a new web app"
    3: Use the built-in domain name supplied by PythonAnywhere for free accounts, which will be yourusername.pythonanywhere.com.  If you are a paying customer, this section of the instructions will be re-visited at a later time.
    4: Click Next.
    5: Select manual configuration as the Python Web framework.
    6: Select python 3.9 as the version.

Step 4: Configure web app tab so that OpenCheckIn functions
    1: In PythonAnywhere, go to the Web tab.
    2: Scroll down to the Virtualenv section of the settings and type in "myenv".  This will link OpenCheckIn with the virtual environment.
    3: Confirm that the virtual environment is found, which should look like: /home/yourusername/.virtualenvs/myenv
    4: Above the section for the Virtualenv is a code section with a link to PythonAnywhere's WSGI configuration file.
    4: Edit the WSGI file.  Large sections of this file need to be deleted.  As shown in the video, remove the FLASK section of the file and the HELLO WORLD section of the file.
    5: Remove comments from the file as specified in the video.  This will now be working code for launching OpenCheckIn.
    6: Update the path so that PythonAnywhere knows where your copy of OpenCheckIn lives.  It will be the directory where the manage.py file is located at and it should be /home/yourusername/OpenCheckIn/
    7: Update the environment module.  Change the module from mysite.settings to open_check_in.settings.
    8: Save the wsgi.py file.

Optional Step: Reload the website settings
    1: In PythonAnywhere, go to the Web tab.
    2: At the top of the Web tab, there is Reload section with a green button that says "Reload yourusername.pythonanywhere.com"
    3: Press this button, and it will begin using the new settings that have been completed.
    4: Open your website yourusername.pythonanywhere.com
    5: There should be a DisallowedHost message.  This message is telling you that OpenCheckIn is properly configured up until this point. You did everything correctly. PythonAnywhere is successfully finding and launching OpenCheckIn.  OpenCheckIn is now working and telling you "I do not recognize PythonAnywhere."

Step 5: Enable PythonAnywhere in OpenCheckIn
    1: In PythonAnywhere, go to the Files tab.
    2: As shown in the video, the settings file should be found at /home/yourusername/OpenCheckIn/open_check_in
    3: Open the file settings.py
    4: The settings file has line numbers on the left side.  Find line number 24, and paste in the proper allowed hosts: "['yourusername.pythonanywhere.com']" Notes: You do not need to keep http or the backslashes.
    5: Before saving and closing the settings.py file, confirm that the DEBUG setting is set to False.  Also take a note of the SECRET_KEY setting that is here.  This current secret key is for evaluation purposes only and you must not use this key in a production environment.  Another video will be made later showing how to easily create new custom secret keys for Django apps to increase your security.
    6: If you do reload and go to OpenCheckIn, it will refuse to load because the table that holds the account user interface preferences is not created yet.(account_uiprefs)  We will create that next.

Step 6: Create database file
    1: In PythonAnywhere, go to the Dashboard tab.
    2: In a Bash console, cut and paste the command "python /home/yourusername/OpenCheckIn/manage.py makemigrations".  This command looks at the functions within OpenCheckIn and sets up the files that will create the database as needed.
    3: Cut and paste the command "python /home/yourusername/OpenCheckIn/manage.py migrate".  The database file will now appear and be ready for use.
    4: Note: Previous commands are saved for a certain time, press the up and down key on your keyboard to access them.
    5: OpenCheckIn is heavily dependent upon its database, and I do not supply a database file.  This is for security reasons.

Step 7: Use OpenCheckIn properly configured on your own web space
    1: In PythonAnywhere, go to the Web tab.
    2: At the top of the Web tab, there is Reload section with a green button that says "Reload yourusername.pythonanywhere.com"
    3: Press this button, and it will begin using the new settings that have been completed.
    4: Open the website yourusername.pythonanywhere.com and now it will work!

Step 8: Collect static dependency files
    1: In PythonAnywhere, go to the Dashboard tab.
    2: In a Bash console, cut and paste the command "python /home/yourusername/OpenCheckIn/manage.py collectstatic" - This will run a process automatically for the necessary site resources.
    3: Type in yes to continue
    4: In PythonAnywhere, go to the Web tab.
    5: Scroll down to the PythonAnywhere Static files section.
    6: Enter the URL: "/static/"
    7: Enter the path: "/home/yourusername/OpenCheckIn/static"
    8: Reload the page again using the green button on the Web tab so that the static files are used.

Step 9: Create administrator
    1: In PythonAnywhere, go to the Dashboard tab.
    2: Cut and paste the command "python /home/yourusername/OpenCheckIn/manage.py createsuperuser" in a Bash console.
    3: Follow the prompts on screen.  For testing, any email address will work but for production purposes please use an email address that is not widely known.
    4: Close the console window.

Step 10: Create OpenCheckIn preferences
    1: Open your website yourusername.pythonanywhere.com/admin
    2: Log in with your credentials.
    3: Go to the preferences on the right side.
    4: Create new preferences.
    5: Go to your homepage yourusername.pythonanywhere.com
    6: Now you should see a background image.
    6: It is strongly advised not to stay logged in as administrator unless necessary.
    7: OpenCheckIn is now fully configured on the server and all administrative functionality is ready for use.
    Note: If your administrator console is not properly showing colors and styling, confirm the section Static files under the Web tab.

In the next couple of days I am planning on uploading the source code for a new project I've been working on for several months.  I'm calling this project Open Check In, and what Open Check In does is focus on streamlining the process of checking in children for churches on Sunday during service.

Open Check In is an application built using Django which means that all of those really useful Python plugins are available for use.  There are plenty I have used, such as OpenCV, which allows me to use a created QR code that is placed within a user's profile and read during the final check-out sequence.  The QR code can be scanned from a phone by a USB web cam which can be initiated by the press of a button on a designated check out screen.

In the initial release, Open Check In is going to be licensed using the GPLv3 licence as I want the kinds of restrictions on my source code afforded by a more robust license.  In an ideal scenario or discussion I find that I agree quite wholly with Linus Torvalds' opinion as to "I give you source code, you give me your changes and we are even" as can be seen in this video.  www.youtube.com/watch?v=PaKIZ7gJlRU

However, this space for churches is almost entirely commercialized and I want to have the time and space in order to build a community of users who potentially fall between the cracks of what those offerings can provide, without having to worry that my code is being used in a way that others are profiting off of or potential situations of misuse that I just simply want to avoid.  I think the users of Open Check In will fall into two primary categories:

1) Churches who simply cannot afford the recurring cost of a month-to-month subscription
2) Churches who may have offline considerations.

To some extent, the vision I have for Open Check In crosses over into the category of an intranet application that is completely disconnected from the wider internet.  Do you want a computer in your back room that broadcasts over your on-prem wifi or wired network to one or a few terminals, maybe you have some slick all-in-one touch screens that were donated by a church member, and all of this can be done easily?  This is one such example.  Just because your church cannot afford a subscription, that doesn't mean you should be forced into doing it manually.

Having seen internal corporate intranet sites, I have been thinking of the kinds of things that might be found on a church intranet if a church or all churches had such intranets.  Maybe church intranets are a thing and I am just totally oblivious.  I do think it's very useful though.  I'm thinking that the kinds of things you would see on such an intranet would be the ability to check in children on Sundays, the ability for members to ask for a Prayer from the Pastor, the ability to schedule or track missionaries, canned messages from the Pastor in a quasi-blog type format that may be present on the screen in the main lobby, and many other things could be potential features that you would expect out of a church intranet.  These are the things(and perhaps others) that are candidates for future enhancements into Open Check In.

Among others goals, Open Check In is not just about the self-contained cost reductions that can be afforded to churches everywhere by embracing this open source technology.  Open Check In is also about finding the most abundant and cost effective off-the-shelf components and breaking any such reliance upon proprietary software or hardware solutions so that a church can leave behind paper-based or spreadsheet based or other manual-heavy approaches without the need to be locked in to any one provider.  The reality is that a church is a non-profit venture, and I think that there ought to be more non-profit options on the same level.

I don't know what all churches need, but I am hoping you will tell me.  And so it is said yes, Open Check In has the potential to be deployed and used in the cloud.  I have not built it with that functionality in mind so I would recommend for now sticking with the intranet based approach.  Wider deployment is a use case that I will one day explore.

A couple of notes about the GPLv3 that I would like to throw out because they are in my thoughts.  I am relying on quite a lot of other components and plugins that are out of my control, and even large portions of "my code" are quite structured in ways that are beyond my control.  Using Django means that in many ways, I have to write my code "the Django way".  Which I am perfectly happy with btw, all I want to do is write a really cool piece of software with amazing features and make sure as many churches as possible are using it.  But I have in mind that if for any reason I need to re-consider licensing out of respect for this or that plugin or Django, Python or whomever other projects out there are due their respect I will be happy to accommodate.  Linus mentions in the video above the "I did something really cool, please use it" BSD license and I might very well explore that later on.

Really cool software, that's all I want.  Really cool software that's open source and compatible with Linux or any other operating system that achieves one or both of the goals of driving down costs for churches everywhere or streamlining in house functionality.

The big corporations are using open source to strictly reign in costs or they are maintaining cost levels while getting many more features.  Why can't a church do the same?

In the coming months I will produce some really-cool and useful how-to videos exploring how to install Open Check In from scratch on bare computers, multi-seat terminals, touch screen kiosks using Porteus, and several other unique and cool ideas.  I also have a Surface tablet that I will explore for potential deployments.  Just a bit of a warning, they will probably be structured as tech demos or boring how-tos, so the excitement will be in the final finished product.

I really think this will be a fun and useful project and I hope many of you will join me as we expand and grow.

After reviewing an issue raised on Github by a user, I pushed changes to the code base that remove the validation around the version of systemd.

This is important, because if you are using an older Linux distro which does not have systemd 236 or greater, EasySeats will not work for you.  Older versions of EasySeats are still available if they are needed, but they are not supported versions.

Get the latest version of EasySeats here: https://github.com/ezst036/EasySeats-releases

After a much longer amount of time than I had anticipated, The next release of EasySeats is available.  This is a very nice update and when I compared how version 7 works, and I am very happy with the current functionality.

For this release, large parts of the program have been re-written.  There have been significant code re-factors and more efficient code reuse which all work to make the program more dynamic when syncing with loginctl.  Second and third and more seats are automatically recognized now, and there is additional logging and error handling.  The functionality for reading from a text file instead of directly from terminal has been removed.  If you need the ability to read a text file instead of reading directly from the terminal for an older distro, version 7 is the last to have this capability.

With the more dynamic nature of this release, EasySeats now keeps a copy of the seats and their status in a series of arrays.  During testing I tried moving, removing, adding, and more, devices to various seats back and forth and it always worked for me.  The one way to produce an error is to assign a seat and then press "cancel" when the root password dialog comes up.  EasySeats assumes that when you move mouse number 2 to seat number 2, that you intend to do this after you press the assign button.  When the root password dialog comes up, the seat number assignment has already been made in the status arrays.

To restore, clear all status and re-get the seats.  To download, the jar file has been uploaded to the releases folder:
https://github.com/ezst036/EasySeats-releases

One of the big reasons that this release was delayed so long was a bug that I ran into that I could not figure out.  My suspicion is that there is a Java versioning issue.  In one of my methods there is a counter variable that is set to 1 instead of zero.  I'm still not sure with 100% certainty, but in order to get this working on multiple distros I put a check in the method that looks at the Java version.  If the Java version is older than 1.9, the counter is incremented.  If not, it stays at zero.

I have several distros that I develop and test on, and in this instance the older version of Fedora I have and the newer version of Ubuntu require different handling for the increment. Hopefully this can be ironed out in the next version.  I will most likely be upgrading several of my computers soon to newer distros, which I think will help bring the issue to its conclusion.

For future testing purposes, I think this version could be very useful.  There is additional logging available by launching EasySeats via the terminal instead of double clicking the jar file.

The seventh release of EasySeats is now out, and with it come an abundance of new features.

• Popup notification for clearing seats
• the window cannot be maximized anymore
• Seat zero can be refreshed from the options menu
• The method which handled single seat creation can also now handle single seat termination
• The drop down is now aware of existing seats

Of these, the most notable item is that there are no limits to the amount of seats now.  With this change, the drop
down list now generally works in a LIFO context when removing seats.  The goal is to eliminate the requirement to clear all seats to start over in case there is a use case of 3 or more seats.

For the most part, program functionality is similar to how it was before with the left <---> right paradigm.  Pick a seat number, add devices from the left side to the right side, and when you are ready you can then assign them to the seat with your chosen configuration.  The permissions pop-up is the point when your seat will actually be created.

A note for future reference:  the next version will be able to automatically pull in data for additional seats, not just seat zero.  This means that the capability to get systemd status out of a text file will be going away.  I could technically make it work by just having one text file per seat, but that begins to defeat the purpose.  It has been over a year since systemd 236 was released, which makes pulling the entries out of the terminal possible.  Version 236 or newer should be in most linux distributions by now.

Adding 4 devices no longer requires typing in the root password 4 times with EasySeats.

I had a thought earlier today that it would be nice if loginctl(systemd) could accept multiple device addresses with only one attach command.  In all that I have read about loginctl, I have never seen anybody do it this way before.  To be clear what I mean is this.  To add multiple devices, I had always assumed that this was necessary:

loginctl attach seat1 (device)
loginctl attach seat1 (device)
​loginctl attach seat1 (device)

Etc, etc.  Tonight after work I attempted adding multiple devices on one line.  I was happy to learn that what I was seeking is already in place.  loginctl will happily work as follows:

loginctl attach seat1 (device) (device) (device) (device) (device)

The best part is, systemd is smart enough that the video card does not necessarily have to be the first device in the list.  It just has to be present in the list.  After rebooting, all the devices I expected were present on seat1.  I tested this with 5 devices on a Solus Linux multiseated install.

One thing I do not want for EasySeats (if I can avoid it) is to have the program store the root password in any way.

EasySeats .06 is now available on GitHub in source or as an executable .jar file.
github.com/ezst036

The latest update makes small changes to some messaging that appears on the terminal if the jar is opened via the command line.

The terminal command "java -jar /home/user/EasySeats.05.1.jar" will launch EasySeats.  As commands are sent and given some will be displayed there.  The installed version of systemd on your distro will be displayed, as will the user's home directory.

The "big" change is the loginctl command being displayed for confirmation purposes.  After you select your device, click add, then click assign, in the terminal the string value "The command that was sent was: " will be followed by what loginctl needs to continue with device assignments.  For example:

"The command that was sent was: loginctl attach seat1 /sys/devices/pci0000:00/0000:00:12.2/usb1/1-6"

Also, the string value "To create a seat, always remember to start with a video card." will appear in the terminal during device assignment.  At its core, EasySeats should be able to facilitate the creation of seats with as little thought as possible, but at the same time it is also a good thing to facilitate the ability to learn how seats are created through simple code and useful feedback.

I recently got my hands on an HP T100 Multiseat Thin Client as it was a really good deal at less than $10.  With it, I wanted to get an idea of the process for setting up multiseat with EasySeats without an additional internal video card. These thin clients work like an external display adapter that also has sound and kb/mouse connectivity options, or at least that is how this HP one is.  I am sure the ones from Plugable and ThinGlobal are the same.

​Below, I am going to create a multiseat setup using only the EasySeats GUI.

Right away, even before attempting to set up additional seats, I was able to use this client to set up a second head for some two-monitor action:

Next, I move to tab 2 and click on usb:1-2 and press "Add", so that this device is moved over to the second list:

Then I click "Assign".  Here, an authentication window will pop up and ask for the administrator password.  This is not a function of EasySeats, this is your distribution letting you know it received a valid command.  Plug in your root password and your seat will be created.  It's that easy.

I do want to note that in the upper middle section of the second tab, the ability to choose other seat numbers is represented by this drop down menu.  So if you wanted to create up to 5 seats, you can.

Once the administrator password has been accepted, the last thing to do is close all applications/windows and reboot.  Once that is complete, the next thing you will see is this:

Voila!  Two seats and zero commands or text files modified in the process.  The cool thing about a thin client like this is that the sound and connectivity interfaces all get transferred over to the new seat with one single click.  Lastly, I log in and request the available seats:

I do not have any PS2 devices and haven't had any for years so I had to plug in the kb and mouse "normally" and use EasySeats to assign them to the second seat.  USB device assignment can be done in real-time, that is, no reboot is required to move USB devices from seat to seat the way it is for a video device.  It is hard to demonstrate in screenshots, but the sound does work as expected with this thin client so both seats have sound.  The Toshiba laptop was released in early 2010.

This is currently running Xubuntu 18.04 with systemd 237 and lightdm.  At this time, systemd and lightdm are the two most important software requirements.  If you have those two, it really doesn't matter too much which distribution you install.  On the hardware side, EasySeats only works when multiple graphics adapters are available.(such as a USB multiseat thin client or a second PCI-E video card)

Personally, I think I would recommend multiple video cards over a USB adapter like this just because its more performant hardware, but of course the only way to multiseat a laptop at this time is with a USB thin client adapter.  During the use of this device, I did notice small graphics performance lags that would not have happened with a card.  And with EasySeats, seat creation and assignment is just a click away.

To recap, the process to create one or more seats is:

1. Launch EasySeats
2. Get devices on tab 1
3. On tab 2, Choose device, press Add
4. Press assign
5. Root password
6. Reboot

Additional insight into creating a seat with EasySeats can be seen on my YouTube page.
www.youtube.com/channel/UCG8dUkyRu3lcyD-GpaZLSMQ

EasySeats Jar files(open and go) can be downloaded from Github: github.com/ezst036

On the GitHub page EasySeats has been updated.  The latest version creates a small text file in the directory /etc/polkit-1/rules.d/20-prevent-shutdown.rules.

This will only work if you first give yourself access to this folder.  In most instances, this folder requires either root or some other high level of permissions in order to access.  EasySeats will see this permission and come back with a popup that you do not have enough privileges for this action.  I chose to go this route as I believe root functions are important to keep separate away from what the program actually does.  Additionally, if the file already exists you will be notified, but it will be up to you to manually delete the file if that is what you choose.

Once you give yourself permissions, what is happening are these instructions:
https://ask.fedoraproject.org/en/question/32900/how-do-i-prevent-users-to-shutdown-the-pc/

But who really wants to mess around with a bunch of text files or other configurations in order to set this up?  Besides permissions of course.  It should just work!

I recently had to call the help desk to have an issue sorted out on my corporate workstation (Windows 7) and as I was sitting there I kept thinking to myself: "Now wouldn't it be great if I could set aside my second monitor as another seat?"

Think about this.  You're working on some big project or preparing for a new project that isn't properly planned or just needs to be completed quickly, and you need some new set of software or permissions for some set of workgroup and then reality sets in.  This is going to require three calls to tech support over the next week.

What an unnecessary frustration.  If only this one computer could be used by two people simultaneously at the same time!

So it may not be a very common occurrence but it certainly seems to happen at the absolute worst times.  Help desk just has to take over your computer remotely while you sit there and watch the mouse move and talk to the person on the other line.

There are a lot of practical uses for having multi-seat capability, even if you are on a computer that you intend to be a permanently single-seat workstation.  There are always those random times here and there where a second person might need access simultaneously.

Now I just wish I had a Linux workstation at work!