szelga

В первом случае вы запускаете python прописанный в пути из переменных окружения, во втором случае - вы запускаете вполне конкретный файл интерпретатора python3
В общем случае - это могут быть два разных интерпретатора лежащих по разным путям и использующим свои библиотеки

зависит от того, как реализовано предоставление доступа у провайдера. не исключено, что будут иметь доступ оба устройства, если провайдер предоставляет IP-адреса из пула немаршрутизируемых в интернете адресов, NAT'ит их на своём маршрутизаторе и не парится насчёт количества абонентских устойств. но такое встречается не часто и только у небольших местечковых провайдеров.

Нужен какой нибудь gunicorn, который будет позволять джанге работать в фоне. Запускать gunicorn и следить за тем, что бы он работал можно каким нибудь supervisor или systemd.
И, чтоб джанга статику не раздавала, в качестве фронтенда Nginx.
Тогда будет по красоте.
Есть ещё вариант Apache + mod_python (кажется так называется) он вроде и проще, но если честно, вообще не серьёзно на мой взгляд, но поиграться хватит это да.

Нужно установить Microsoft Visual C++ 14.0. Только не Redistributable, а Microsoft Visual C++ Build Tools.

Если бы вы не перехватывали все исключения, то знали бы причину.

MyUser.password видимо хранит хешированный пароль (или вы его храните в открытом виде?). И при User.set_password() получается хеш от хеша

Правило простое: если метод производит действия над группой экземпляров, то помещаем его в менеджер, а если над одним экземпляром, то в модель.

И ещё на счёт increase_views — не советую так делать. Если в одно время случится два вызова, то значение увеличится не на два, а лишь на единицу. Значение нужно увеличивать на стороне БД — благодаря транзакционности будут учтены оба вызова. На Django ORM это выглядит так:

from django.db.models import F

class Quiz(models.Model):
    ...
    def increase_views(self):
        self.__class__.objects.filter(pk=self.pk).update(views=F('views') + 1)

Разделить уровни, и каждый своим способом.
Физический - берём план здания, рисуем где расположены розетки абонентов (или не розетки, а просто коннекторы), нумеруем их все (этаж, помещение, номер розетки в помещении; или другим вариантом).
В серверной все концы загоняем на патч-панели. Вызваниваем всё и заносим в табличку - номер патч-панели, порт патч-панели, вид соединения (до абонента, на вышестоящий узел, или что ещё), кабель (и его длина, если известна), что на втором конце (розетка, коннектор, или просто смотан кабель за потолком в виде резерва), номер розетки/коннектора/конца кабеля. Можно и чуть проще или чуть сложнее, кому как удобно. И в принципе всё.

Какой MAC на каком порту и какой на нём IP (и есть ли там IP вообще) - это уже всё любыми средствами мониторинга и/или инвентаризации, их много.

В итоге менять табличку надо только если добавляются/убираются линии, или переносятся из кабинета в кабинет. Ну и на схеме менять обозначения и расположение розеток (если нужно это кому-то). Перепланировки помещений тоже не так часто, можно всё вручную поправить.
А мониторинг будет отслеживать остальное - на каком порту какого коммутатора какой MAC, какой IP на нём, и т.п.

В принципе, на СКС есть стандарты ISO и ГОСТ. Лень гуглить, но я их читал, там прописано если не всё, то практически всё, нужно только соблюдать.