lauantai 20. huhtikuuta 2024

Reolink-820a

Reolink-820a liittyviä muistiinpanoja.

URL

  • ONVIF: http://etuovi.home:8000/onvif/device_service
  • Streams
    • 4K: rtsp://user:password@etuovi.home:554/
    • 4K: rtsp://user:password@etuovi.home/Preview_01_main
    • JPEG: https://etuovi.home/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=sdaf&user=user&password=password
      • curl --insecure -X GET "https://etuovi.home/cgi-bin/api.cgi?cmd=Snap&channel=0&rs=sdaf&user=user&password=password" -o snapshot.jpg

Proxmox Zoneminder VM

Luotu VM Zoneminderille käyttäen Debianin ISOa. IP 192.168.1.69 ja DNS-nimi zoneminder.home. Vastaa osoitteessa http://zoneminder.home/zm

Asennettu Zoneminder asennusohjeiden mukaisesti: https://zoneminder.readthedocs.io/en/latest/installationguide/debian.html

Komennot:
apt update && apt upgrade

apt install mariadb-server

mariadb

CREATE DATABASE zm;

CREATE USER zmuser@localhost IDENTIFIED BY 'zmpass';

GRANT ALL ON zm.* TO zmuser@localhost;

FLUSH PRIVILEGES;

exit;

apt install zoneminder

mariadb -u zmuser -p zm < /usr/share/zoneminder/db/zm_create.sql # passwd zmpass

chgrp -c www-data /etc/zm/zm.conf
a2enconf zoneminder
a2enmod cgi
systemctl reload apache2.service
systemctl restart zoneminder.service
systemctl status zoneminder.service


Konfattu Reolink-820A Zoneminderin UI:sta. Kamera löytyy ONVIF:llä. Streamin tallennus passthrough ja jpeg-tallennus poistettuna.

ONVIF: http://etuovi.home:8000/onvif/device_service

Zoneminderilla ei näemä juuri tee mitään, jos streamia tallentaa passthrough. Esikatselu ei toimi H.265:llä, eikä oikein  muutakaan pysty tekemään. Mutta toimii videoiden tallentimena, jos ei muuten jaksa säätää.

 

 

 

 

 

 

 

 

maanantai 15. huhtikuuta 2024

Proxmox MQTT LXC

Luotu tteck:n skriptillä MQTT LXC. IP 192.168.1.230 ja lisäksi annettu DNS-nimi mqtt.home.

Luotu salasanatiedosto ja lisätty se /etc/mosquitto/passwd. Ilman salasanatiedostoa Mosquitto ei lähde käyntiin.

sunnuntai 14. huhtikuuta 2024

Proxmox NFS-palvelin

Levyjakoon virtuaalikoneiden välillä tarvitaan NFS-palvelin tai vastaava.

Käyttäen jälleen tteck:n valmista skriptiä, luotu Debian 12 VM. Koneella muistia 1 GB ja levyä 2 GB

Asetettu koneen hostname

hostnamectl set-hostname nfs

Lisätty koneelle Proxmoxin UI:sta 1500GB erillinen levy, joka jaetaan. Levy näkyy /dev/sdb:ssä.

Koneelle pääsee Proxmoxin shellistä käyttäjänä root ilman salasanaa.

Luotu koneelle fdiskillä primääripartitio 1, jolle annettu kaikki tila.

Luotu ext4-tiedostojärjestelmä.

$ mkfs.ext4 /dev/sdb1

 Lisätty /etc/fstab seuraavat rivit

# NFS levyjako

UUID=8e029af8-e8f5-45bb-a5ad-8f0de77cf4aa /mnt/nfs ext4 defaults,errors=remount-ro  0 1

 

 Ajettu seuraavat komennot

apt-get update

apt install nfs-kernel-server -y

systemctl start nfs-kernel-server

systemctl enable nfs-kernel-server

systemctl status nfs-kernel-server

chown nobody:nogroup /mnt/nfs

chmod 755 /mnt/nfs

Lisätty tiedostoon rivi /etc/exports

/mnt/nfs 192.168.1.0/24(rw,sync,no_subtree_check)

 Exportataan jaettu hakemisto

exportfs -a

 Lisätty lokaaliin DNS:ään koneen IP 192.168.1.90 nimelle nfs.home.

Testattu Ubuntu-koneella, että yhteys toimii.

sudo apt-get install nfs-common

sudo mount -o hard,rsize=1048576,wsize=1048576,timeo=600 nfs.home:/mnt/nfs /mnt/nfs

 

 

 

 

 

 

 

Proxmox ja NUC

 Muistiinpanot Proxmox-asennuksesta NUC:lle: 11. sukupolven Intel NUC11ATKPE emolevy (vuoden 2022 mallisto), Intel Pentium Silver N6005 suoritin, Intel UHD Graphics (32EU) integroitu näytönohjain, 2 kpl SO-DIMM DDR4 2933MHz muistipaikka (32GB max.), M.2 PCIe Gen3x2 / SATA3 SSD kiintolevypaikka, 1kpl HDMI 2.0b näyttöliitäntä, 1kpl DisplayPort 1.4 näyttöliitäntä, 4kpl USB 3.2 Gen1/2, 2kpl USB 2.0, 1kpl 1Gbps verkkoliitäntä, sisäänrakennettu Wireless-AC langaton verkkokortti. (lainaus Terastoren sivuilta)


Asennus perustuu näihin ohjeisiin: https://www.derekseaman.com/2023/10/home-assistant-proxmox-ve-8-0-quick-start-guide-2.html

Lisäksi käytetty näitä apuskriptejä https://tteck.github.io/Proxmox/

Proxmox-asennus

Asennus tehty Proxmox 8.1.4-versiolla. Asennuksen aikana menty oletusasetuksilla.
Tällaiset lisäsäädöt tehty asennuksen aikana:
  1. Laitettu koneen nimeksi nucci.home
  2. Laitettu nucci.home paikalliseen DNS:ään
  3. Annettu kiinteä IP-osoite 192.168.1.141
Asennuksen jälkeen ajettu tteck Proxmox VE Post Install, joka konfasi käytössä olevat repot, asensi päivitykset ja poisti high availabilityn pois käytöstä (ja jotain pienempää).

Asennettu myös uusin prosessorin mikrokoodi intel-microcode_3.20240312.1~deb12u1_amd64.deb (käyttäen tteck-skriptiä).

Home Assistant -asennus

Asennettu tteck-skriptillä Home Assistant OS VM 12.2.

Asetettu kiinteä IP ja nimi homeassistant.home.

Home Assistantin oma asennus huomasi heti Shellyn sekä Reolinkin kameran.

Lisätty Proxmoxiin "Use USB Vendor / Device ID" (passthrough), jossa Z-Stick 7. Tällä pitäisi saada Z-Wave-laitteet näkymään.

Asennettu Home Assistantiin Z-Wave JS addon. Päivitetty Z-Stick 7 versioon 7.18.8 käyttäen HA:n addonia. Eri versioissa on bugeja ja uusinta versiota ei edes kannata asentaa tällä hetkellä. Ohjeita löytyy täältä: https://aeotec.freshdesk.com/support/solutions/articles/6000263744-update-z-stick-7-with-z-wavejs-ui

Paineltu yksitellen Fibaro Dimmer 2 (FGD-212) läpi. Lisäksi käyty läpi Fibari Single Switch 2 (FGS-213) läpi.

sunnuntai 25. helmikuuta 2018

Using NGINX as web cache

Sometimes you have to work with an HTTP(S) service that's too slow for your purposes. For example, you might have to test your service against HTTP based interface, which takes ages to respond and you don't want to spend too much testing time on waiting responses to see how your latest code change behaves. If it's ok to use cached data, you can use NGINX as web cache and proxy all your requests through it. If you have already used the same request before (most likely test code generates the same request all over again), NGINX doesn't call the real HTTP interface. Instead, it's returning a cached response you got previously.

Here's a working configuration for setting up NGINX for caching site https://www.uta.fi.

events {
  worker_connections  4096;  ## Default: 1024
}
 
http {
  proxy_cache_path /tmp/nginx-proxy levels=1:2 keys_zone=my_cache:10m max_size=10g
                 inactive=1y use_temp_path=off;
  proxy_hide_header       Set-Cookie;
  proxy_ignore_headers    Set-Cookie;
  server {
      listen   80;
      location / {
          proxy_send_timeout   180s;
          proxy_read_timeout   180s;
 
          proxy_cache my_cache;
          proxy_cache_valid 200 1y;
          proxy_pass https://www.uta.fi;
      }
  }
}

This configuration stores up to 10GB of cached data for 1 year. The local cache path is set to existing directory /tmp/nginx-proxy.

To use NGINX, you don't have to install it locally. I prefer using Docker images. You can run the example above with the following command.

docker run -d --rm -p 1001:80 --name nginx-cache \
-v /tmp/proxy-blog/nginx-proxy.conf:/etc/nginx/nginx.conf:ro \
-v /tmp/proxy-blog/proxy-local-directory:/tmp/nginx-proxy nginx

After the command, point your browser at http://localhost:1001 and see the results. The command assumes that you have saved the NGINX configuration listed above as /tmp/proxy-blog/nginx-proxy.conf and that you have directory /tmp/proxy-blog/proxy-local-directory on your computer (the Docker host).

sunnuntai 14. tammikuuta 2018

Clustered Quartz setup

This blog post is about configuring clustered Quartz with static configuration i.e. the job configuration remains the same for each software version.

Running clustered Quartz is easy, but it's not easy to setup the cluster. The problem is that how do you create and update Quartz jobs of a running system. In some systems, you might do the configuration by hand directly to database. In other systems, you want to avoid manual steps and let the system update itself automatically during version updates. Because I normally automate the installation of the projects I'm involved with, I want that the system does job maintenance automatically without manual database updating.

Quartz provides several examples for different kinds of use cases. One of the examples (example 13 in version 2.2.3) cover clustered Quartz. The example assumes that the processes are started so that the person or software that starts the process, knows when to clean existing jobs and when not. I don't find this approach very useful in real life, although it is of course a simple example.

When the Quartz using process starts, the process should somehow know when to update the jobs. This is somewhat difficult problem to solve. You shouldn't update jobs while they're running, because you might end up running the same job twice (even simultaneously), which is not nice behavior. You should also create the job configuration exactly once per system version (unless you're managing dynamically changing jobs).

One way to solve the job updating problem is that one of the nodes in the cluster knows that it's the primary (or lead or whatever) node and that it's also the first running node in the cluster. Only primary node is allowed to update the job configuration and other nodes are running against the configuration created by primary node. In my solution, primary node removes job data completely and recreates it based on the current configuration.

public void initialize() throws SchedulerException {
  if (quartzNodeDao.isPrimary()) {
    // only the "lead" process gets to update the jobs. Jobs are updated by removing all job data and recreating it    
    scheduler.clear();
    final int SECOND = 1 * 1000;
    this.demoTrigger = createTrigger(SECOND);
    JobDetail importJobDetail = JobBuilder
        .newJob(DemoJob.class)
        .withIdentity(DEMO_JOB, DEMO_GROUP)
        .storeDurably()
        .requestRecovery()
        .build();

    System.out.println("Chosen as master, created new scheduled job");
    scheduler.scheduleJob(importJobDetail, demoTrigger);
  } else {
    System.out.println("Not master, skipping job creation");
  }
}

The key thing in this solution is that each starting cluster node tries to insert the GIT software revision of the current release to the database and if the node is successful, it's the primary node.

public boolean isPrimary() {
  String sql = "INSERT INTO build_revision (revision) VALUES (?);";
  try(Connection connection = dataSource.getConnection()) {
    connection.setAutoCommit(false);
    try (PreparedStatement ps = connection.prepareStatement(sql)) {
      connection.setAutoCommit(false);
      ps.setString(1, revision);
      ps.executeUpdate();
      connection.commit();
      // insert was successful, so the caller is primary node      return true;
    }
  } catch (Exception e) {
    // Should be handled better in real life, but handling ignored in demo.
    // Most likely insert failed, because entry exists already, so caller
    // is not primary node.
    return false;
  }
}

After the Quartz job configuration has been done, it's irrelevant which one of the nodes is primary, because the job configuration won't change before next version. It's assumed that all the nodes are stopped in the installation so that only one version of the software is running at any given point of time. This solution works very nicely at least in AWS ECS environment.

Here's link to complete project: https://github.com/perttuta/quartz