If you're inventing and pioneering, you have to be willing to be misunderstood for long periods of time
Wanted to test Centos 8 so created docker image to test it.
This is my Dockerfile
FROM centos:latest
RUN yum -y install httpd; yum clean all; systemctl enable httpd.service
EXPOSE 80
CMD ["/usr/sbin/init"]
Build image
docker build --rm -t local/c8-systemd-httpd .mintty screen dump
$ nslookup.exe -type=SOA -debug roo.ee
Non-authoritative answer:
------------
Got answer:
HEADER:
opcode = QUERY, id = 1, rcode = NXDOMAIN
header flags: response, want recursion, recursion avail.
questions = 1, answers = 0, authority records = 1, additional = 0
QUESTIONS:
8.49.98.192.in-addr.arpa, type = PTR, class = IN
AUTHORITY RECORDS:
-> 98.192.in-addr.arpa
ttl = 2797 (46 mins 37 secs)
primary name server = sjoki.uta.fi
responsible mail addr = vg.sjoki.uta.fi
serial = 2019030709
refresh = 28800 (8 hours)
retry = 7200 (2 hours)
expire = 1209600 (14 days)
default TTL = 86400 (1 day)
------------
Server: UnKnown
Address: 192.98.49.8
------------
Got answer:
HEADER:
opcode = QUERY, id = 2, rcode = NOERROR
header flags: response, want recursion, recursion avail.
questions = 1, answers = 1, authority records = 2, additional = 0
QUESTIONS:
roo.ee, type = SOA, class = IN
ANSWERS:
-> roo.ee
ttl = 13889 (3 hours 51 mins 29 secs)
primary name server = ns1.dbweb.ee
responsible mail addr = hostmaster.roo.ee
serial = 2017102701
refresh = 14400 (4 hours)
retry = 3600 (1 hour)
expire = 1209600 (14 days)
default TTL = 86400 (1 day)
AUTHORITY RECORDS:
-> roo.ee
nameserver = ns1.dbweb.ee
ttl = 3272 (54 mins 32 secs)
-> roo.ee
nameserver = ns2.dbweb.ee
ttl = 3272 (54 mins 32 secs)
------------
roo.ee
ttl = 13889 (3 hours 51 mins 29 secs)
primary name server = ns1.dbweb.ee
responsible mail addr = hostmaster.roo.ee
serial = 2017102701
refresh = 14400 (4 hours)
retry = 3600 (1 hour)
expire = 1209600 (14 days)
default TTL = 86400 (1 day)
roo.ee
nameserver = ns1.dbweb.ee
ttl = 3272 (54 mins 32 secs)
roo.ee
nameserver = ns2.dbweb.ee
ttl = 3272 (54 mins 32 secs)
Found a nice picture explains very well differences between symmetric encryption versus asymmetric encryption
Nüüd kus mul on 1MHz colpitts signaali generaator valmis tuleks genereeritavat signaali hakata võimendama. Kogun siia power amplifier (PA) kohta informatsiooni.
Küsimused, millele ma praegu vastust otsin:
Hea video PA kohta
When you look at the winds aloft report the wind direction usually varies at 3, 6, 9, and 12 thousand feet. Average the wind direction from the winds aloft report and the surface wind. Use that average as a guide. Example:
| Altitude | Direction |
| Surface | 240 |
| 3000 | 260 |
| 6000 | 270 |
| 9000 | 270 |
| 12000 | 290 |
1330 / 5 = 266 Degree
Freefall Drift=Average wind during freefall/duration of freefall x 5280 feet
Example:
| Altitude | Velocity(knots) |
| 3000 | 15 |
| 6000 | 22 |
| 9000 | 28 |
| 12000 | 35 |
100 / 4 = 25 knots25 knots/60 seconds x 5280 feet = 2,165 feetRounded to 2,000 feet of approximate Freefall Drift
Software: Hortonworks HDF
OS: RHEL 7.x
Set up two Schema Registries. Modified schema registries configuration in a way that Kerberos SPN are similar. Defaul Ambari set up SPN as SERVICE/FQDN@REALM.
Set up AWS ELB.
When requesting a resource I got on success response and one Error 403 GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
After shut down one schema registry turned out all request were ok, so second schema registry responded every time GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)
Used kvno for debugging
In first server:
[root@ip-10-113-86-26 ~]# kvno -k /etc/security/keytabs/spnego.service.keytab HTTP/registry.dp.example.net
HTTP/registry.dp.example.net@DP.EXAMPLE.NET: kvno = 3, keytab entry valid
In second server:
[root@ip-10-113-86-4 ~]# kvno -k /etc/security/keytabs/spnego.service.keytab HTTP/registry.dp.example.net
HTTP/registry.dp.example.net@DP.EXAMPLE.NET: kvno = 3, keytab entry invalid
[root@ip-10-113-86-4 ~]# klist -kte /etc/security/keytabs/spnego.service.keytab
Keytab name: FILE:/etc/security/keytabs/spnego.service.keytab
KVNO Timestamp Principal
—- ——————- ——————————————————
2 05/22/2019 13:56:14 HTTP/ip-10-113-86-4.eu-central-1.compute.internal@DP.EXAMPLE.NET (aes128-cts-hmac-sha1-96)
2 05/22/2019 13:56:14 HTTP/ip-10-113-86-4.eu-central-1.compute.internal@DP.EXAMPLE.NET (aes256-cts-hmac-sha1-96)
2 05/22/2019 13:56:14 HTTP/ip-10-113-86-4.eu-central-1.compute.internal@DP.EXAMPLE.NET (arcfour-hmac)
2 05/22/2019 13:56:14 HTTP/ip-10-113-86-4.eu-central-1.compute.internal@DP.EXAMPLE.NET (des3-cbc-sha1)
2 05/22/2019 13:56:14 HTTP/ip-10-113-86-4.eu-central-1.compute.internal@DP.EXAMPLE.NET (des-cbc-md5)
2 05/22/2019 14:16:11 HTTP/registry.dp.example.net@DP.EXAMPLE.NET (aes256-cts-hmac-sha1-96)
2 05/22/2019 14:16:11 HTTP/registry.dp.example.net@DP.EXAMPLE.NET (aes128-cts-hmac-sha1-96)
[root@ip-10-113-86-4 ~]# kadmin -s 10.113.86.28 -p admin/admin
Authenticating as principal admin/admin with password.
Password for admin/admin@DP.EXAMPLE.NET:
kadmin: getprinc HTTP/registry.dp.example.net@DP.EXAMPLE.NET
Principal: HTTP/registry.dp.example.net@DP.EXAMPLE.NET
Expiration date: [never]
Last password change: Wed May 22 14:16:48 UTC 2019
Password expiration date: [never]
Maximum ticket life: 1 day 00:00:00
Maximum renewable life: 0 days 00:00:00
Last modified: Wed May 22 14:16:48 UTC 2019 (admin/admin@DP.EXAMPLE.NET)
Last successful authentication: [never]
Last failed authentication: [never]
Failed password attempts: 0
Number of keys: 2
Key: vno 3, aes256-cts-hmac-sha1-96
Key: vno 3, aes128-cts-hmac-sha1-96
MKey: vno 1
Attributes:
Policy: [none]
kadmin:
The problem is that in case you use kadmin ktadd it will increase printcipal KVO
I have always problem how to know where defined variables I can see via Ambari GUI – {{ some text }}
First this pattern is called Jinja Template framework
Lets learn via example
I have HDF schema registry and I don’t like in example kerberos.principal value Ambari puts there HTTP/[hostname]@REALM. I put two schema registries behind AWS EBL and I need static SPN.
Jinja template is found /var/lib/ambari-agent/cache/common-services/REGISTRY/0.3.0/package/templates/registry.yaml.j2
From template I can find {{registry_ui_jaas_principal}}
Ambari uses lots of params.py files to generate variables. The one I am interested in is /var/lib/ambari-agent/cache/common-services/REGISTRY/0.3.0/package/scripts/params.py and it is copy of /var/lib/ambari-server/resources/mpacks/hdf-ambari-mpack-3.3.1.0-10/common-services/REGISTRY/0.3.0/package/scripts/params.py
Do not change file under cache because after ambari restart static one will overwrites this so change
/var/lib/ambari-server/resources/mpacks/hdf-ambari-mpack-3.3.1.0-10/common-services/REGISTRY/0.3.0/package/scripts/params.py
(echo >/dev/tcp/[FQDN]/[port]) &>/dev/null && echo “open” || echo “close”
Test it.
Open in one terminal port (in example 8081) with
nc -l 8081
In second terminal
cat > /dev/tcp/localhost/8081
margusja@IRack:~$ cat </dev/tcp/[ssh server]/22
SSH-2.0-OpenSSH_7.4
Juhtusin lugema ühte ülilihtsat selgitust, mis seletas nn “Common Emitter” transistori kasutegurit (gain).
Allikas: https://www.electronics-tutorials.ws/transistor/tran_1.html
Antud juhul võimendatakse voolu e väike hulk voolu, mis liigub baasist emitteri kaudu lubab palju suuremal voolul liikuda kollektorist (C) liikuda emiterisse (E) ehk “voltage gain” beeta on harilikult 50 kuni 200.
Kui me nüüd lepime kokku, et beeta on 100, siis ühe elektroni liikumisel B -> E liigub 100 elektroni C -> E.
Kui teemaks on transistor ja võimendus e transistor töötab oma nn aktiivalas, siis on väga oluline mida ja kui palju anda baasile peale e base “transistor biasing”
https://www.electrical4u.com/common-emitter-amplifier/