tinc is a great mesh Virtual Private Network daemon, with just one little glitch (and also little crypto problems ;-). I find its configuration really tedious and complicated compared to OpenVPN and its possibility to centrally assign IP addresses and push options to clients. I know, that’s the tax for being mesh, but wouldn’t it be great to configure your mesh network a bit centrally ?
Sometime it’s needed to selectively route specified IPs or networks via different interface – i.e. if you want to route private addresses over VPN (a.k.a split tunnel routing) or to route some public IPs over VPN to unblock some nationally restricted sites (Netflix). Here are simple scripts to achieve this.
If you are trying to access site with self-signed certificate with Firefox 31 (or later) and get Issuer certificate is invalid error (sec_error_ca_cert_invalid), you have to disable new mozilla::pkix certificate verification.
In about:config set
security.use_mozillapkix_verification = false
To find out more about mozilla::pkix and why your firefox just got so super secure and paranoid, that it doesn’t allows you to access you own site without googling – see https://wiki.mozilla.org/SecurityEngineering/Certificate_Verification. I’m only wondering, why did they renamed it from insanity::pkix to mozilla::pkix – do they confess that ‘mozilla’ is slowly becoming a synonym for ‘insane’ ?-) Throwing such an error without any hint or possiblity to add an exception (as usual) is IMHO insane – but, who cares about power users today…
Update: As noted in comments, this should not work in Firefox 33 (or later).
- Your internal CA certificate doesn’t specifies CA:TRUE in X509v3 Basic Constraints section
- You self-signed server certificate (the last one in certificate chain) specifies CA:TRUE – what is default for certificates generated by pkitool script from easy-rsa suite – and you have your CA certificate installed in FF.
See also FF bug #1042889.
Update3: Thanks to the work of, there is a fix for this in Firefox 31 ESR (
I’ve encountered unusual problem while dumping one postgresql database. Every try to run pg_dump resulted in this:
sam@cerberus:~/backup$ pg_dump -v -c js1 >x pg_dump: Error message from server: ERROR: invalid memory alloc request size 18446744073709551613 pg_dump: The command was: COPY job.description (create_time, job_id, content, hash, last_check_time) TO stdout; pg_dump: *** aborted because of error
sam@cerberus:~/backup$ pg_dump -v -c --inserts js1 >x pg_dump: Error message from server: ERROR: invalid memory alloc request size 18446744073709551613 pg_dump: The command was: FETCH 100 FROM _pg_dump_cursor pg_dump: *** aborted because of error
Few weeks ago I’ve encountered almost fatal failure of two(!) disks in my RAID5 array – well really funny situation, and a bit uncomfortable way how to find out why not having monitoring and alarming system is a really bad idea 😉
Fortunately no serious data damage happened, postgresql seemed to recover from this, without any problems and my databases worked fine – until I’ve tried to perform a database dump.
And now comes the important question, how to find out which table rows are incorrect (and pg_filedump says everything is OK) ?
And the answer is, use custom function:
CREATE OR REPLACE FUNCTION find_bad_row(tableName TEXT) RETURNS tid as $find_bad_row$ DECLARE result tid; curs REFCURSOR; row1 RECORD; row2 RECORD; tabName TEXT; count BIGINT := 0; BEGIN SELECT reverse(split_part(reverse($1), '.', 1)) INTO tabName; OPEN curs FOR EXECUTE 'SELECT ctid FROM ' || tableName; count := 1; FETCH curs INTO row1; WHILE row1.ctid IS NOT NULL LOOP result = row1.ctid; count := count + 1; FETCH curs INTO row1; EXECUTE 'SELECT (each(hstore(' || tabName || '))).* FROM ' || tableName || ' WHERE ctid = $1' INTO row2 USING row1.ctid; IF count % 100000 = 0 THEN RAISE NOTICE 'rows processed: %', count; END IF; END LOOP; CLOSE curs; RETURN row1.ctid; EXCEPTION WHEN OTHERS THEN RAISE NOTICE 'LAST CTID: %', result; RAISE NOTICE '%: %', SQLSTATE, SQLERRM; RETURN result; END $find_bad_row$ LANGUAGE plpgsql;
It goes over all records in given table, expands them one by one – what will results in exception if some expansion occurs. Exception will also contain CTID of last correctly processed row. And next row with higher CTID will be the corrupted one.
js1=# select find_bad_row('public.description'); NOTICE: LAST CTID: (78497,6) NOTICE: XX000: invalid memory alloc request size 18446744073709551613 find_bad_row -------------- (78497,6) (1 row) js1=# select * from job.description where ctid = '(78498,1)'; ERROR: invalid memory alloc request size 18446744073709551613 js1=# delete from job.description where ctid = '(78498,1)'; DELETE 1 js1=# select find_bad_row('job.description'); NOTICE: rows processed: 100000 NOTICE: rows processed: 200000 NOTICE: rows processed: 300000 NOTICE: rows processed: 400000 NOTICE: rows processed: 500000 NOTICE: rows processed: 600000 NOTICE: rows processed: 700000 NOTICE: rows processed: 800000 find_bad_row -------------- (1 row)
Note: this function requires hstore postgresql extension – it is part of postgresql distribution, you may need to create it with:
CREATE EXTENSION hstore;
Records in this table are not that important, and I can restore them from external source – so I could delete this corrupted row. If you can’t you will have to play directly with data files – like described here – good luck 🙂
This script monitors SMART attributes of given disks using smartctl (smartmontools).
This one monitors some interesting values of MegaRaid adapter physical drives using MegaCli tool.
Description how to use them can be found within scripts itself – enjoy 😉