Den onsdag 29. januar 2025 08.05.39 +01.00 skrev Petter Reinholdtsen pere@hungry.com:
[Ole Aamot]
- Petter, tilbyr du en offisiell Nikita DB-installasjon på UiO for
testing?
Nei. Maskinen vi har fått tildelt er kun tilgjengelig internt ved UiO, og skal i denne omgang brukes til å teste mot UiOs egne løsninger. OK, proprietært som gpt.uio.no som henter kapital fra ikke-UiO institusjoner?
Jeg setter pris på all hjelp før jeg går over til plan B: å skrive ut alle skriptene på papir og sende dem med brevduer til PostgreSQL-hovedkvarteret.
Det høres ut som et solid slag i luften. Antagelig mer produktivt å lese dokumentasjon. :)
PostgreSQL 14, 16, 17?
PostgreSQL 14: https://www.postgresql.org/docs/
PostgreSQL 16: PostgreSQL: Documentation: 16: Chapter 21. Client Authentication https://www.postgresql.org/docs/16/client-authentication.html
PostgreSQL 17: PostgreSQL: Documentation: 17: 20.1. The pg_hba.conf File https://www.postgresql.org/docs/current/auth-pg-hba-conf.html
Hva tenker Dere om denne sludderbotløsningen, Thomas og Petter?
Jeg tenker PostgreSQL-oppsettet må justeres til å tillate oppkobling for nikita-bruker fra aktuell maskin. :) [ /etc/postgresql/14/main/pg_hba.conf ]
- +local nikita postgres 127.0.0.1/32 peer # TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only local all all peer # IPv4 local connections: -host all all 127.0.0.1/32 md5 +host all all 127.0.0.1/32 scram-sha-256 # IPv6 local connections: -host all all ::1/128 md5 +host all all ::1/128 scram-sha-256 # Allow replication connections from localhost, by a user with the # replication privilege. local replication all peer -host replication all 127.0.0.1/32 md5 -host replication all ::1/128 md5 +host replication all 127.0.0.1/32 scram-sha-256 +host replication all ::1/128 scram-sha-256 +host archives ole 127.0.0.1/32 md5 +host archives ole ::1/128 md5
ole@lov:/etc/postgresql/14/main$ sudo diff -uN pg_ident.conf~ pg_ident.conf --- pg_ident.conf~ 2024-01-09 12:45:41.889129534 +0100 +++ pg_ident.conf 2025-01-29 20:40:16.734662222 +0100 @@ -40,3 +40,4 @@ # ----------------------------------
# MAPNAME SYSTEM-USERNAME PG-USERNAME +nikita nikita nikita
Jeg gikk i gang og opprettet databasen 'archives' og brukeren 'nikita' som Unix-bruker 'postgres'.
$ sudo su - postgres $ createdb archives $ createuser nikita
$ psql -d template1 psql (14.15 (Ubuntu 14.15-0ubuntu0.22.04.1), server 10.23 (Ubuntu 10.23-0ubuntu0.18.04.2)) Type "help" for help.
Opprettet deretter passwd tabellen:
template1=# CREATE TABLE passwd ( user_name text UNIQUE NOT NULL, pwhash text, uid int PRIMARY KEY, gid int NOT NULL, real_name text NOT NULL, home_phone text, extra_info text, home_dir text NOT NULL, shell text NOT NULL );
INSERT INTO passwd VALUES ('nikita', 'NorgeMot2030',0,0,"Nikita","004748055666",null,"/data/","/bin/dash");
template1=# ALTER USER nikita WITH PASSWORD 'NorgeMot2030'; ALTER ROLE template1=#
postgres@lov:~$ psql -h localhost -U nikita -d archives Password for user nikita: psql (14.15 (Ubuntu 14.15-0ubuntu0.22.04.1), server 10.23 (Ubuntu 10.23-0ubuntu0.18.04.2)) SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off) Type "help" for help.
archives=>
og koblet til localhost som 'nikita' til databasen 'archives'
$ psql -h localhost -U nikita -d archives
En burde sannsynligvis deretter opprette tabellene accounts, users, persons og definere rollen managers og account_managers som ROLE, i tillegg til å definere regelverk for account_managers og user_policy som POLICY i psql.
DROP TABLE accounts; DROP TABLE users; CREATE TABLE accounts (manager text, company text, contact_email text); ALTER TABLE accounts ENABLE ROW LEVEL SECURITY; CREATE ROLE managers; CREATE TABLE users (person text, birthday date, user_name text, contact_email text); ALTER TABLE users ENABLE ROW LEVEL SECURITY; CREATE ROLE persons; CREATE POLICY account_managers ON accounts TO managers USING (manager = current_user); CREATE POLICY user_policy ON users USING (user_name = current_user);
DROP TABLE archives;
CREATE TABLE archives ( archive_id SERIAL PRIMARY KEY, name TEXT NOT NULL, uri TEXT NOT NULL, type BOOLEAN, latitude DOUBLE PRECISION NOT NULL, longitude DOUBLE PRECISION NOT NULL, description TEXT NOT NULL );
GRANT SELECT ON archives TO PUBLIC; GRANT SELECT, UPDATE, INSERT ON archives TO users; INSERT INTO users (person, birthday, user_name, contact_email) VALUES ('Ole', '1978-02-20', 'ole', 'ole@aamot.org'); GRANT SELECT (uri), UPDATE (uri) ON archives TO accounts;
For å definere et overordnet databaseskjema og regler for arkivene hos Arkivverket, kan vi sette opp et strukturert system som integrerer både digitale og fysiske arkiver, samt gir administratorer og brukere nødvendige tilganger. Her er et forslag til hvordan dette kan struktureres: Databasen Tabeller 1. Archives * Beskrivelse: Representerer både digitale og fysiske arkiv. * Attribute Eksempler: * archive_id(Primærnøkkel) * uri(URI for digitale arkiver) * physical_location(Lokasjonsnavn, som kan lage en kobling med lat/long) * latitude(Breddegrad for fysisk arkiv) * longitude(Lengdegrad for fysisk arkiv) * type(Digital/Fysisk) * description(Beskrivelse av arkivet) 2. Users * Beskrivelse: Representerer administratorene som har ulike tilgangsnivåer. * Attribute Eksempler: * user_id(Primærnøkkel) * name(Navn på brukeren) * email(E-postadresse) * role(Administratorrolle) * permissions(Liste over tillatelser) 3. Accounts * Beskrivelse: Representerer tilgjengelige lese- og skrivemetoder samt tilgangen brukerne har. * Attribute Eksempler: * account_id(Primærnøkkel) * user_id(Fremmednøkkel refererer til Users) * archive_id(Fremmednøkkel refererer til Archives) * access_type(Les/Skriv) * timestamp(Når tilgangen ble gitt eller modifisert) Overordnede Regler for Tilgang og Interaksjon 1. Tilgangsregler: * Administratorer får tildelt rollebasede tillatelser som definert iUsers-tabellen. * Bare brukere med spesifikke tillatelser kan opprette, modifisere eller slette arkivposter. 2. Dataintegritet: * Forsikre at allearchive_idoguser_idiAccountser gyldige referanser til eksisterende poster i henholdsvisArchivesogUsers. 3. Loggføring og Sporing: * Spor alle lese- og skriveoperasjoner gjennomAccounts-tabellen for revisjon og sikkerhet. 4. Lokasjonsdata for Fysiske Arkiver: * Sørg for nøyaktige lokasjonsdata iArchivesfor å fasilitere fysisk gjenfinning. 5. UI Integrering: * Arkiver kan aksesseres via brukergrensesnitt som kobles sammen URI for digitale arkiver og geografisk data for fysiske samlinger. Ved å implementere dette systemet, vil Arkivverket kunne effektivisere administrasjonen av både digitale og fysiske arkiver, samtidig som tilgang og sikkerhet ivaretas på en strukturert måte.
Mvh,Ole Aamot