PowerDNS on PostgreSQL
CREATE TABLE domains (
id serial NOT NULL,
name character varying(255) NOT NULL,
master character varying(20),
last_check integer,
"type" character varying(6) NOT NULL,
notified_serial integer,
account character varying(40)
);
CREATE TABLE records (
id serial NOT NULL,
domain_id integer,
name character varying(255),
"type" character varying(6),
content character varying(255),
ttl integer,
prio integer,
change_date integer
);
CREATE TABLE supermasters (
ip character varying(25) NOT NULL,
nameserver character varying(255) NOT NULL,
account character varying(40)
);
COPY domains (id, name, master, last_check, "type", notified_serial, account) FROM stdin;
1 kuszelas.eu \N \N NATIVE \N \N
\.
--
-- Data for TOC entry 22 (OID 17153)
-- Name: records; Type: TABLE DATA; Schema: public; Owner: postgres
--
COPY records (id, domain_id, name, "type", content, ttl, prio, change_date) FROM stdin;
2 1 localhost.kuszelas.eu A 127.0.0.1 120 \N \N
20 1 kuszelas.eu MX mail2.kuszelas.eu 300 10 \N
21 1 mail2.kuszelas.eu A 212.182.115.24 120 \N \N
1 1 kuszelas.eu SOA localhost user.kuszelas.eu 1 86400 \N \N
17 1 kuszelas.eu NS ns.kuszelas.eu 300 \N \N
18 1 kuszelas.eu MX mail.kuszelas.eu 300 5 \N
12 1 _jabber._tcp.jabber.kuszelas.eu SRV 0 5269 kuszelas.eu 300 10 \N
13 1 _xmpp-server._tcp.jabber.kuszelas.eu SRV 0 5269 kuszelas.eu 300 10 \N
14 1 _xmpp-client._tcp.jabber.kuszelas.eu SRV 0 5222 kuszelas.eu 300 10 \N
16 1 kuszelas.eu TXT Serwer 300 \N \N
3 1 www.kuszelas.eu A 195.242.124.71 120 \N \N
5 1 dns.kuszelas.eu A 195.242.124.71 120 \N \N
6 1 ftp.kuszelas.eu A 195.242.124.71 120 \N \N
7 1 poczta.kuszelas.eu A 195.242.124.71 120 \N \N
8 1 pop3.kuszelas.eu A 195.242.124.71 120 \N \N
9 1 smtp.kuszelas.eu A 195.242.124.71 120 \N \N
10 1 ssh.kuszelas.eu A 195.242.124.71 120 \N \N
11 1 jabber.kuszelas.eu A 195.242.124.71 120 \N \N
4 1 mail.kuszelas.eu A 195.242.124.71 120 \N \N
\.
Audit trail:
CREATE TABLE audit_domains (
operation char(1) NOT NULL,
stamp timestamp NOT NULL,
userid text NOT NULL,
id serial NOT NULL,
name character varying(255) NOT NULL,
master character varying(20),
last_check integer,
"type" character varying(6) NOT NULL,
notified_serial integer,
account character varying(40)
);
CREATE TABLE audit_records (
operation char(1) NOT NULL,
stamp timestamp NOT NULL,
userid text NOT NULL,
id serial NOT NULL,
domain_id integer,
name character varying(255),
"type" character varying(6),
content character varying(255),
ttl integer,
prio integer,
change_date integer
);
CREATE OR REPLACE FUNCTION process_audit_domains() RETURNS TRIGGER AS $audit_domains$
BEGIN
--
-- Create a row in audit_domains to reflect the operation performed on domains,
-- make use of the special variable TG_OP to work out the operation.
--
IF (TG_OP = 'DELETE') THEN
INSERT INTO audit_domains SELECT 'D', now(), user, OLD.*;
RETURN OLD;
ELSIF (TG_OP = 'UPDATE') THEN
INSERT INTO audit_domains SELECT 'U', now(), user, NEW.*;
RETURN NEW;
ELSIF (TG_OP = 'INSERT') THEN
INSERT INTO audit_domains SELECT 'I', now(), user, NEW.*;
RETURN NEW;
END IF;
RETURN NULL; -- result is ignored since this is an AFTER trigger
END;
$audit_domains$ LANGUAGE plpgsql;
CREATE TRIGGER audit_domains
AFTER INSERT OR UPDATE OR DELETE ON domains
FOR EACH ROW EXECUTE PROCEDURE process_audit_domains();
--
CREATE OR REPLACE FUNCTION process_audit_records() RETURNS TRIGGER AS $audit_records$
BEGIN
--
-- Create a row in audit_records to reflect the operation performed on records,
-- make use of the special variable TG_OP to work out the operation.
--
IF (TG_OP = 'DELETE') THEN
INSERT INTO audit_records SELECT 'D', now(), user, OLD.*;
RETURN OLD;
ELSIF (TG_OP = 'UPDATE') THEN
INSERT INTO audit_records SELECT 'U', now(), user, NEW.*;
RETURN NEW;
ELSIF (TG_OP = 'INSERT') THEN
INSERT INTO audit_records SELECT 'I', now(), user, NEW.*;
RETURN NEW;
END IF;
RETURN NULL; -- result is ignored since this is an AFTER trigger
END;
$audit_records$ LANGUAGE plpgsql;
CREATE TRIGGER audit_records
AFTER INSERT OR UPDATE OR DELETE ON records
FOR EACH ROW EXECUTE PROCEDURE process_audit_records();
| PowerDNS on PostgreSQL | | 2007.12.14-17:28.00
dd_rescue /dev/zero test
host:/fs/t# dd_rescue /dev/zero test
dd_rescue: (info): ipos: 5831680.0k, opos: 5831680.0k, xferd: 5831680.0k
errs: 0, errxfer: 0.0k, succxfer: 5831680.0k
+curr.rate: 493402kB/s, avg.rate: 141304kB/s, avg.load: 34.6%
host:/fs/t# dd_rescue /dev/zero test
dd_rescue: (info): ipos: 22496256.0k, opos: 22496256.0k, xferd: 22496256.0k
errs: 0, errxfer: 0.0k, succxfer: 22496256.0k
+curr.rate: 366322kB/s, avg.rate: 150428kB/s, avg.load: 38.7%
IO/s: 590
Write BW: 148MB/s
host:/fs/t# time dd_rescue -w /dev/zero test
dd_rescue: (info): ipos: 535740416.0k, opos: 535740416.0k, xferd: 535740416.0k
errs: 0, errxfer: 0.0k, succxfer: 535740416.0k
+curr.rate: 28755kB/s, avg.rate: 151774kB/s, avg.load: 41.6%
real 58m53.858s
user 0m25.982s
sys 24m2.210s
| dd_rescue /dev/zero test | | 2007.12.13-18:51.00
Vista ReadyBoost requirements
: 5MB/s(2.5M/s?) for random reads (4k) 3MB/s(1.75M/s?) for random writes (512k) Limits defined in: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\EMDMgmt for example: Device Status 0x02 ReadSpeedKBs 0x1000 WriteSpeedKBs 0x1000 (you need to click 'do-not-retest', otherwise it will otherwrite your changes in registy)| Vista ReadyBoost requirements | | 2007.12.08-14:18.00
Compaq 6910p on debian lenny
- kernel >=2.6.22 (for sound, intel x3100 graphics)
- xorg >=7.2
- alsaconfig -> snd_hda_intel
- iwlwifi-4965-ucode -> /lib/firmware/
- iwlwifi 1.2.22 (1.2.20 doesn't work)
- s2ram -f --vbe_save --vbe_post --vbe_mode
Setting Process Title On Linux
http://www.netsplit.com/2007/01/ and http://lightconsulting.com/~thalakan/process-title-notes.html with perl: Sys::Proctitle,| Setting Process Title On Linux | | 2007.11.29-13:20.00
Vserver VS OpenVZ - benchmark/posgresql/jira test
Jira reindex, same hardware, same database, with db on linux-vserver(2.6.18.8+vs2.0.3):"Re-Indexing was successful and took: 1518 seconds."
with db on openvz (2.6.18+ovz028stab047.1):"Re-Indexing was successful and took: 1488 seconds."
db on openvz, running on only one virtual cpu (vzctl set --cpus 1):"Re-Indexing was successful and took: 1681 seconds."
HW: HP ProLiant DL360 G4 model name : Intel(R) Xeon(TM) CPU 3.00GHz
| Vserver VS OpenVZ - benchmark/posgresql/jira test | | 2007.11.27-21:03.00
Anti-RRD, don't loose information
logs are precious, rrd believes otherwise, that wouldn't be a problem if rrd wasn't so popular. Thus, one needs tool that sits on top of rrd/modifies rrd, and stop it from erasing data. That is the most economical course of action, since every data logging tool outthere uses rrd.How to proceed?
- cron-fired tool that backs rrd-data into separate file
- patch to rrd, that stores removed data in alternate data stream (another file), with a little effort this might become an option to rrd, making historical data easily available to rrd-based tools
| Anti-RRD, don't loose information | | 2007.11.20-09:17.00
Reverse Munin
- install reverse-munin, it reports stats every ~15m (stats collected every ~30s)| Reverse Munin | | 2007.11.19-22:42.00
Effect of CONCURRENCY_LEVEL variable on make-kpkg (kernel compilation) on dual Quad Core
System:processor : 7 vendor_id : GenuineIntel cpu family : 6 model : 15 model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz stepping : 7 cpu MHz : 2333.422 cache size : 4096 KB physical id : 1 siblings : 4 core id : 3 cpu cores : 4 fpu : yes fpu_exception : yes cpuid level : 10 wp : yes flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall lm constant_tsc pni monitor ds_cpl vmx est tm2 cx16 xtpr lahf_lm bogomips : 4667.06 clflush size : 64 cache_alignment : 64 address sizes : 36 bits physical, 48 bits virtual power management: .... model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz model name : Intel(R) Xeon(R) CPU E5345 @ 2.33GHz Linux etchdev386 2.6.18.bsd40j-vz #1 SMP Sun Oct 28 10:14:55 UTC 2007 i686 GNU/Linux
CL real user sys 1 36m8.773s 28m0.017s 5m11.427s 2 21m17.209s 28m19.778s 5m32.009s 3 16m24.912s 28m24.875s 5m47.002s 4 14m54.012s 28m30.863s 6m0.895s 5 14m50.449s 28m27.211s 6m4.799s 6 15m33.589s 28m15.798s 5m58.850s 7 16m23.849s 28m28.563s 6m5.475s 8 17m41.355s 28m16.958s 6m0.515s 9 17m49.368s 28m29.867s 6m3.207s 10 18m21.491s 28m26.071s 6m4.455s 11 18m46.612s 28m32.743s 6m6.239s 12 19m10.218s 28m31.855s 6m5.335s 13 19m36.510s 28m25.191s 6m2.123s 14 19m33.238s 28m45.360s 6m8.467s 15 19m50.454s 28m47.152s 6m10.283s 16 20m21.163s 28m42.168s 6m11.019s 17 19m56.470s 28m41.992s 6m5.219s 18 19m49.307s 28m48.364s 6m11.235s 19 19m56.618s 28m45.544s 6m11.047s 20 20m12.434s 28m51.164s 6m12.847s 21 20m37.028s 28m34.055s 6m9.423s 22 19m56.581s 29m0.861s 6m21.540s 23 20m52.650s 28m46.000s 6m10.259s 24 20m17.952s 28m41.556s 6m14.103s 25 20m39.504s 28m42.468s 6m14.483s 26 19m56.328s 29m26.562s 6m28.620s 27 20m0.562s 29m31.551s 6m36.301s 28 19m57.038s 29m34.491s 6m32.289s 29 20m3.414s 29m29.779s 6m33.901s 30 20m15.452s 29m38.131s 6m36.489s 31 19m58.292s 29m36.491s 6m35.749s 32 20m29.804s 28m57.513s 6m20.204s 33 20m8.699s 28m59.293s 6m23.452s 34 20m11.357s 28m55.916s 6m20.216s 35 20m31.274s 28m49.472s 6m14.579s 36 20m20.033s 28m48.772s 6m18.116s
2.6.22-amd64: (without vz)CL real user sys 1 36m9.151s 28m0.961s 5m13.396s 2 21m16.693s 28m15.106s 5m35.113s 3 16m14.933s 28m40.860s 5m53.790s 4 14m51.212s 28m30.335s 6m0.811s 5 14m49.351s 28m31.207s 6m7.995s 6 15m47.585s 28m11.794s 5m58.182s export CONCURRENCY_LEVEL=6 ... real 9m51.049s user 32m8.349s sys 5m31.861s
# chroot on 2.6.18/amd64CL real user sys 1 35m47.262s 31m56.732s 4m24.081s 2 18m55.905s 31m26.558s 4m27.733s 3 13m46.587s 31m34.278s 4m28.333s 4 11m9.684s 31m26.130s 4m32.769s 5 9m40.245s 31m51.495s 4m41.050s 6 8m43.968s 32m3.032s 4m45.382s 7 8m7.112s 32m4.800s 4m45.218s 8 7m54.335s 32m8.845s 4m48.246s 9 8m14.461s 32m32.178s 4m53.662s 10 8m47.419s 33m1.660s 4m56.667s 11 9m48.772s 33m30.070s 4m59.543s 12 11m13.929s 33m35.218s 5m0.759s
# 2.6.22-vz004(git @ 2007-11-01) (amd64)CL real user sys 1 39m0.566s 30m12.521s 4m26.485s 2 22m15.543s 30m34.999s 4m41.694s 3 17m15.496s 31m3.320s 4m52.818s 4 15m13.936s 31m14.269s 5m3.363s 5 15m7.533s 31m13.217s 5m4.987s 6 15m30.503s 31m25.142s 5m17.580s
with vzctl set etchdev --cpus 5:CL real user sys 1 71m38.213s 27m44.876s 4m41.790s 5 31m17.052s 28m24.655s 5m27.836s 6 32m49.246s 28m5.849s 5m13.568s CL: 1 real 35m55.736s user 27m54.469s sys 5m13.696s CL: 2 real 21m21.611s user 28m13.954s sys 5m29.397s CL: 3 real 17m3.690s user 28m25.743s sys 5m43.485s CL: 4 real 15m42.706s user 28m26.507s sys 5m53.898s CL: 5 real 16m59.589s user 28m3.105s sys 5m49.130s CL: 6 real 18m24.560s user 28m12.538s sys 5m52.138s CL: 7 real 19m22.321s user 27m57.009s sys 5m51.942s
with vzctl set etchdev --cpus 4:CL: 1 real 35m25.464s user 28m0.665s sys 5m7.427s CL: 2 real 21m12.749s user 28m26.247s sys 5m28.245s CL: 3 real 17m9.802s user 28m26.435s sys 5m38.409s CL: 4 real 16m55.358s user 28m17.830s sys 5m40.993s CL: 5 real 18m58.317s user 27m52.749s sys 5m36.249s CL: 6 real 19m57.399s user 27m47.980s sys 5m35.565s CL: 7 real 20m26.853s user 27m58.965s sys 5m36.873s
with vzctl set etchdev --cpus 3:CL: 1 real 35m6.224s user 27m55.997s sys 4m58.507s CL: 2 real 21m38.178s user 28m55.168s sys 5m44.654s CL: 3 real 17m36.461s user 28m47.816s sys 5m42.417s CL: 4 real 19m50.483s user 28m6.361s sys 5m34.001s CL: 5 real 20m58.151s user 28m21.998s sys 5m47.946s CL: 6 real 21m36.935s user 28m23.494s sys 5m46.558s CL: 7 real 22m8.818s user 28m9.370s sys 5m37.545s
with vzctl set etchdev --cpus 2:CL: 1 real 34m11.380s user 28m1.933s sys 4m52.270s CL: 2 real 21m7.797s user 28m37.959s sys 5m12.724s CL: 3 real 22m4.511s user 28m4.549s sys 5m13.984s CL: 4 real 22m42.487s user 28m6.717s sys 5m12.572s CL: 5 real 24m43.785s user 28m1.637s sys 5m14.804s CL: 6 real 24m9.467s user 28m12.986s sys 5m15.120s CL: 7 real 24m49.795s user 28m4.093s sys 5m7.071s
.| Effect of CONCURRENCY_LEVEL variable on make-kpkg (kernel compilation) on dual Quad Core | | 2007.11.13-15:19.00
85C errors with 1-wire termometer
from http://www.nabble.com/Problem-with-temperature-reading-t3265726.htmlby David Lissiuk Feb 21, 2007; 07:13pm Hi all, As I have done fairly extensive testing of various 1-wire issues I can maybe help shed some light on possible hardware causes of seeing 85.0C errors for those new to these issues. In general a 85.0C reading indicates that a POR has occurred in the chip: The following issues are common, note that not all are things that software alone can correct. 1) Poor 1-wire line levels A). If the chip is wired for parasitic operation, the VDD line must be grounded. Otherwise unknown parasitic results may occur. (This is not required with -PAR devices, which are internally grounded inside the chip). B). While operating under powered mode of operation, the power supply has to have a reasonably fast rise time, else the chip may enter an internal test mode. The voltage should ideally be 5 volts to insure maximum signal headroom for the 1-wire signal. Line losses through the cable need to be considered. C). The slave device (the DS18B20) may not have enough power/current to complete the temperature conversion and this may cause a POR to occur in the chip instead (Generating the 85.0C reading). This may be caused by the following: 2). Insufficient weak-pull-up current on simple 1-wire bus master designs I've seen issues when the weak-pull up current is insufficient, causing the chip to do a POR during the temp conversion time. Generally a value between 1.1K and 2.5K for the weak pull-up resistor is what I recommend. I've often seen this problem on bus master designs using a 4.7K or greater weaker pull-up resistors. 3) Insufficient conversion time/current. Parasitic driven devices take considerably longer to do their conversion than a powered device does (for this reason I generally recommend powered sensors (See 1WRJ45 for one way how to supply power through a cable). You will get a 85.0 result if the conversion has not completed and a POR had occurred previously. A powered device temperature conversion is typically around 650ms at 12bits (750ms max). The DS18B20 uses a relatively crude internal timing oscillator. And variations from both, temperature and internal chip composition, etc. may effect the duration needed for a successful temperature conversion cycle to complete, and the chip may draw as much as 1.5ma during the conversion processes. This may be why one chip works and the other doesn't if you're just marginal with the timings. (generally a good time to redesign your network to fix the fundamental problems). I have heard of one batch of DS18X20's working in a circuit and another not due to these slight internal differences on marginal designed networks. This is not a failure of the parts, just of poor network design and is generally corrected by insuring sufficient conversion current is received by the temperature device for the entire temperature conversion cycle. Powered temperature sensors may also be polled for when the temperature conversion is complete (thus saving time). See the datasheet for more information on this. Another source of errors is too long delays in providing a strong pull-up current for parasitic device. The sensor is issued a conversion command, but a strong pull-up current is not applied for one reason or another and the device loses power. This is only an issue with parasitic operated devices obviously. It is generally a poor bus master design or improper programming of the strong pull-up of the bus master. 4), Current supply limitations: Since during a temperature conversion current use in the device can be fairly high, (1.5ma max by spec) limitation of the network design may affect this supplied current. A). Limitations of the Bus master to supply conversion current. A LINK based design bus master can supply more current than a DS2480B design (DS9097U-S09). A DS2490 (USB) can supply slightly more current than a DS2480B unit. The Impedance matching line filter on the bus master must also be considered if added to a DS9097U-S) or USB unit (Generally a highly recommended practice to add the filter for signal reflection issues). If the bus master is also parasiticlly powered this may also be an issue or limitation. B). Any additional bus line resistance. The use of a DS2409 adds additional current limiting to what can be supplied to downstream devices. Each channel of a DS2409 has a different resistance. So channel use may also effect operation. In addition the DS2409 chip package sets the maximum pass-gate current to 20ma max. according to Dallas (info not in data sheet) This can be a limitation in any attempt to do bulk temperature conversions of parasitic downstream devices. C) Time delays generated by inline devices A DS2409 can also cause a POR to occur on a temperature sensor after switching channels using a smart-on command. (There are several errors in the DS2409 data sheet that I've notified Dallas about, including the flow diagram. Dallas has verified them and is correcting them in a new revision of the data sheet. Though I am not sure if all of them will be corrected by then). Much of this information has been developed in my efforts on basic research for a hardware book on 1-wire I am developing in my free time (Still in early stages of writing, as I have very little of that. I do however welcome suggestions and reports of problems that need to be researched (contact me off list)). I hope this information can be of help by the software writers in understanding some of the possible conditions that can cause the reporting of a 85.0C error in the software that should be considered. As you can see when reporting an 85.0C error it might also be useful to others to report the bus master used, any line filter, the number and channels used in any hubs (and the hub design being used), along with the temperature sensor wiring (powered or parasitic), the delivered power voltage and the chip revision if known. Hope this helps the software efforts, Cheers David Lissiuk Sr. Computer Scientist Springbok Digitronics
| 85C errors with 1-wire termometer | | 2007.11.12-09:35.00
BSD - Bastard patcheset for Linux kernel. 2.6.18-bsd40n-ovz
Sat Nov 10 13:38:45 CET 2007 Realtek's r8168 driver, this one works reliably with:04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
in contrast to lenny's r8169 driver which oops'es every ~few hours with:------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:721! invalid opcode: 0000 [#1] SMP Modules linked in: vznetdev vzethdev vzrst vzcpt vzdquota vzmon vzdev ipt_ttl xt_tcpmss ipt_TCPMSS ipt_tos ext2 mbcache xt_length xt_CLASSIFY iptable_mangle cls_u32 sch_sfq sch_htb ipt_MASQUERADE ipt_REDIRECT iptable_nat ip_nat xt_multiport ipt_REJECT xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables ata_piix ip_set softdog tg3 evdev parport_pc pcspkr parport rtc xfs dm_mirror dm_log dm_snapshot dm_mod raid10 raid456 xor raid1 raid0 multipath linear md_mod ide_disk ahci libata sd_mod 8139too jmicron ehci_hcd aic7xxx uhci_hcd e100 8139cp generic scsi_transport_spi mii r8169 ide_core scsi_mod usbcore thermal processor fan CPU: 3, VCPU: -1.3 EIP: 0060:[<c0220b2d>] Not tainted VLI EFLAGS: 00010202 (2.6.18.bsd40l-vz #1) EIP is at pskb_expand_head+0x20/0x115 eax: 00000001 ebx: f58a2600 ecx: ffffffe2 edx: f71b6900 esi: f71b6800 edi: 00000000 ebp: 00000002 esp: f7a45e24 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, veid: 0, ti=f7a44000 task=f7a9e640 task.ti=f7a44000) Stack: f6ea9d8c f7a5991c f58a2600 f78172e0 f7817000 00000002 c022120a 00000020 02000000 0000003a f78172e0 f7817000 f58a2600 f8a28674 f71b6910 f6f6e000 f7a59918 f687b600 0000003c f6f6e3c0 f8a7c000 00000000 dd66a540 f687b600 Call Trace: [<c022120a>] skb_pad+0xa0/0x10b [<f8a28674>] rtl8169_start_xmit+0x222/0x370 [r8169] [<c0224f6f>] dev_hard_start_xmit+0x1a7/0x1fd [<c0232d25>] __qdisc_run+0xf5/0x1d1 [<c0226974>] dev_queue_xmit+0x142/0x24a [<c025e717>] arp_xmit+0x4e/0x50 [<c025fb66>] arp_solicit+0x14e/0x158 [<c022b9b9>] neigh_timer_handler+0x247/0x2aa [<c022b772>] neigh_timer_handler+0x0/0x2aa [<c0124820>] run_timer_softirq+0x10e/0x177 [<c012067e>] __do_softirq+0x84/0x109 [<c0120739>] do_softirq+0x36/0x3a [<c010344b>] apic_timer_interrupt+0x1f/0x24 [<c0101842>] mwait_idle+0x25/0x38 [<c0101807>] cpu_idle+0x5e/0x74 Code: 00 00 5e e9 f7 08 f4 ff 5b 5e c3 55 57 89 d7 56 53 89 c3 83 ec 08 8b 90 b0 00 00 00 8b b0 a4 00 00 00 8b 80 a0 00 00 00 48 74 0b <0f> 0b 66 b8 d1 02 b8 a3 77 2a c0 29 f2 8d 44 17 1f 8b 54 24 1c EIP: [<c0220b2d>] pskb_expand_head+0x20/0x115 SS:ESP 0068:f7a45e24 Kernel panic - not syncing: Fatal exception in interrupt ..... .... ..... Unbalanced enable for IRQ 169 BUG: warning at kernel/irq/manage.c:118/enable_irq() [<c01485a9>] enable_irq+0x54/0x87 [<f8a9d8ba>] probe_hwif+0x556/0x627 [ide_core] [<c020c4b8>] __driver_attach+0x0/0x5d [<f8a9e1b5>] probe_hwif_init_with_fixup+0xb/0x63 [ide_core] [<f8a9ff89>] ide_setup_pci_device+0x3c/0x6d [ide_core] [<f8a2411e>] generic_init_one+0x92/0xa0 [generic] [<c01bd75c>] pci_device_probe+0x36/0x57 [<c020c419>] driver_probe_device+0x42/0x8b [<c020c4f0>] __driver_attach+0x38/0x5d [<c020bf3a>] bus_for_each_dev+0x33/0x55 [<c020c383>] driver_attach+0x11/0x13 [<c020c4b8>] __driver_attach+0x0/0x5d [<c020bc53>] bus_add_driver+0x64/0xfd [<c01bd898>] __pci_register_driver+0x47/0x63 [<c013c175>] sys_init_module+0x16c9/0x184c [<c016c454>] cp_new_stat64+0xfd/0x10f [<f8a3cdf8>] e100_probe+0x2ea/0x5f7 [e100] [<f8a3c7b0>] e100_get_wol+0xc/0x2d [e100] [<f8a3c6c0>] e100_get_drvinfo+0x1b/0x4c [e100] [<f8a3c7d8>] e100_set_wol+0x7/0x41 [e100] [<f8a3b000>] e100_setup_ucode+0x0/0xcc [e100] [<f8a3c494>] e100_tx_clean+0x3a/0xb8 [e100] [<f8a3c800>] e100_set_wol+0x2f/0x41 [e100] [<c010297f>] syscall_call+0x7/0xb ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:721! invalid opcode: 0000 [#1] SMP Modules linked in: vznetdev vzethdev vzrst vzcpt vzdquota vzmon vzdev ipt_ttl xt_tcpmss ipt_TCPMSS ipt_tos ext2 mbcache xt_length xt_CLASSIFY iptable_mangle cls_u32 sch_sfq sch_htb ipt_MASQUERADE ipt_REDIRECT iptable_nat ip_nat xt_multiport ipt_REJECT xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables ata_piix ip_set softdog tg3 rtc parport_pc evdev parport pcspkr xfs dm_mirror dm_log dm_snapshot dm_mod raid10 raid456 xor raid1 raid0 multipath linear md_mod ide_disk sd_mod ahci libata jmicron 8139too ehci_hcd e100 aic7xxx scsi_transport_spi scsi_mod uhci_hcd generic ide_core 8139cp r8169 mii usbcore thermal processor fan CPU: 0, VCPU: -1.0 EIP: 0060:[<c0220b2d>] Not tainted VLI EFLAGS: 00010202 (2.6.18.bsd40l-vz #1) EIP is at pskb_expand_head+0x20/0x115 eax: 00000001 ebx: da11a980 ecx: ffffffe2 edx: eca99f00 esi: eca99e00 edi: 00000000 ebp: 00000002 esp: c030fe48 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, veid: 0, ti=c030e000 task=c02c26c0 task.ti=c030e000) Stack: f74a7d8c f6ebeadc da11a980 f78fc2e0 f78fc000 00000002 c022120a 00000020 02000000 0000003a f78fc2e0 f78fc000 da11a980 f8a47674 eca99f10 f6f3f000 f6ebead8 f6c97600 0000003d f6f3f3d0 f8a2a000 00000000 f0f7cc80 f6c97600 Call Trace: [<c022120a>] skb_pad+0xa0/0x10b [<f8a47674>] rtl8169_start_xmit+0x222/0x370 [r8169] [<c0224f6f>] dev_hard_start_xmit+0x1a7/0x1fd [<c0232d25>] __qdisc_run+0xf5/0x1d1 [<c0226974>] dev_queue_xmit+0x142/0x24a [<c025e717>] arp_xmit+0x4e/0x50 [<c025fb66>] arp_solicit+0x14e/0x158 [<c022b9b9>] neigh_timer_handler+0x247/0x2aa [<c022b772>] neigh_timer_handler+0x0/0x2aa [<c0124820>] run_timer_softirq+0x10e/0x177 [<c012067e>] __do_softirq+0x84/0x109 [<c0120739>] do_softirq+0x36/0x3a [<c010344b>] apic_timer_interrupt+0x1f/0x24 [<c0101842>] mwait_idle+0x25/0x38 [<c0101807>] cpu_idle+0x5e/0x74 [<c0314723>] start_kernel+0x39c/0x3a3 Code: 00 00 5e e9 f7 08 f4 ff 5b 5e c3 55 57 89 d7 56 53 89 c3 83 ec 08 8b 90 b0 00 00 00 8b b0 a4 00 00 00 8b 80 a0 00 00 00 48 74 0b <0f> 0b 66 b8 d1 02 b8 a3 77 2a c0 29 f2 8d 44 17 1f 8b 54 24 1c EIP: [<c0220b2d>] pskb_expand_head+0x20/0x115 SS:ESP 0068:c030fe48 Kernel panic - not syncing: Fatal exception in interrupt ------------[ cut here ]------------ kernel BUG at net/core/skbuff.c:721! invalid opcode: 0000 [#1] SMP Modules linked in: vznetdev vzethdev vzrst vzcpt vzdquota vzmon vzdev ipt_ttl xt_tcpmss ipt_TCPMSS ipt_tos ext2 mbcache xt_length xt_CLASSIFY iptable_mangle cls_u32 sch_sfq sch_htb ipt_MASQUERADE ipt_REDIRECT iptable_nat ip_nat xt_multiport ipt_REJECT xt_limit xt_tcpudp xt_state ip_conntrack nfnetlink iptable_filter ip_tables x_tables ata_piix ip_set softdog tg3 parport_pc parport rtc pcspkr evdev xfs dm_mirror dm_log dm_snapshot dm_mod raid10 raid456 xor raid1 raid0 multipath linear md_mod ide_disk ahci libata jmicron sd_mod aic7xxx generic scsi_transport_spi ehci_hcd uhci_hcd e100 8139too 8139cp scsi_mod mii r8169 ide_core usbcore thermal processor fan CPU: 1, VCPU: -1.1 EIP: 0060:[<c0220add>] Not tainted VLI EFLAGS: 00010202 (2.6.18.bsd40m-vz #1) EIP is at pskb_expand_head+0x20/0x115 eax: 00000001 ebx: d2f5a500 ecx: ffffffe2 edx: d9ad1b00 esi: d9ad1a00 edi: 00000000 ebp: 00000002 esp: f7a03e24 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, veid: 0, ti=f7a02000 task=f7abf220 task.ti=f7a02000) Stack: f6e73d8c f7d5bc9c d2f5a500 f78c02e0 f78c0000 00000002 c02211ba 00000020 02000000 0000003a f78c02e0 f78c0000 d2f5a500 f8a285cc d9ad1b10 f79c7000 f7d5bc98 f6ee3a00 00000030 f79c7300 f8a3c000 00000000 f6f26680 f6ee3a00 Call Trace: [<c02211ba>] skb_pad+0xa0/0x10b [<f8a285cc>] rtl8169_start_xmit+0x222/0x370 [r8169] [<c0224f1f>] dev_hard_start_xmit+0x1a7/0x1fd [<c0232cd5>] __qdisc_run+0xf5/0x1d1 [<c0226924>] dev_queue_xmit+0x142/0x24a [<c025e6be>] arp_xmit+0x4e/0x50 [<c025fb0d>] arp_solicit+0x14e/0x158 [<c022b969>] neigh_timer_handler+0x247/0x2aa [<c022b722>] neigh_timer_handler+0x0/0x2aa [<c0124820>] run_timer_softirq+0x10e/0x177 [<c012067e>] __do_softirq+0x84/0x109 [<c0120739>] do_softirq+0x36/0x3a [<c010344b>] apic_timer_interrupt+0x1f/0x24 [<c0101842>] mwait_idle+0x25/0x38 [<c0101807>] cpu_idle+0x5e/0x74 Code: 00 00 5e e9 47 09 f4 ff 5b 5e c3 55 57 89 d7 56 53 89 c3 83 ec 08 8b 90 b0 00 00 00 8b b0 a4 00 00 00 8b 80 a0 00 00 00 48 74 0b <0f> 0b 66 b8 d1 02 b8 72 77 2a c0 29 f2 8d 44 17 1f 8b 54 24 1c EIP: [<c0220add>] pskb_expand_head+0x20/0x115 SS:ESP 0068:f7a03e24 Kernel panic - not syncing: Fatal exception in interrupt| BSD - Bastard patcheset for Linux kernel. 2.6.18-bsd40n-ovz | | 2007.11.11-22:42.00
BSD - Bastard patcheset for Linux kernel. 2.6.18-bsd40m
Thu Nov 1 13:38:45 CET 2007 Backports for r8169 support, JMicron PATA support. Various fixes.. OpenVZ 028stab047.1 plus compilation fix| BSD - Bastard patcheset for Linux kernel. 2.6.18-bsd40m | | 2007.11.01-14:42.00
Compiling kernels inside openvz
Contenders:simfs 112G 26G 87G 23% / /dev/shm 2.0G 369M 1.7G 18% /home/eyck/ramdysk
Fight:export CONCURRENCY_LEVEL=8 eyck@etchdev386:~/40m-ovz/work$ time nice rm -r linux* patches Patching.log && time sh rediff.sh ... make[1]: Leaving directory `/home/eyck/40m-ovz/work/linux-2.6.18' ====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]====== This is kernel package version 10.067. echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 17m19.657s user 28m30.859s sys 6m11.603s real 18m3.658s user 28m44.144s sys 6m40.757s
export CONCURRENCY_LEVEL=8 eyck@etchdev386:~/ramdysk/40m-ovz/work$ time nice rm -r linux* patches Patching.log && time sh rediff.sh .... ====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]====== This is kernel package version 10.067. echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 17m19.916s user 28m14.074s sys 5m35.077s real 17m56.725s user 28m26.523s sys 5m52.778s
Soo... it looks like (since this machine has 14G ram) it managed too cache all the files, and there's no visible advantage to using ramdisc. And now without openvz overhead:export CONCURRENCY_LEVEL=8 .... make[1]: Leaving directory `/home/eyck/ramdysk/40m-ovz/work/linux-2.6.18' ====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]====== This is kernel package version 10.067. echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 17m36.922s user 28m8.894s sys 5m30.633s real 18m13.800s user 28m21.430s sys 5m48.630s
export CONCURRENCY_LEVEL=8 .... make[1]: Leaving directory `/home/eyck/40m-ovz/work/linux-2.6.18' ====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]====== This is kernel package version 10.067. echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 17m55.724s user 28m26.759s sys 6m2.363s real 18m45.132s user 28m39.971s sys 6m31.328s
eyck@codev64:~/40m-ovz/work$ export CONCURRENCY_LEVEL=16 eyck@codev64:~/40m-ovz/work$ time nice rm -r linux* patches Patching.log && time sh rediff.sh cp -pf debian/control.dist debian/control make[1]: Leaving directory `/home/eyck/40m-ovz/work/linux-2.6.18' ====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]====== This is kernel package version 10.067. echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 20m5.180s user 28m41.280s sys 5m57.190s real 20m52.680s user 28m54.396s sys 6m26.556s eyck@codev64:~/40m-ovz/work$ export CONCURRENCY_LEVEL=4 ... ====== making target stamp-kernel-headers [new prereqs: linux-headers-2.6.18.bsd40l-vz linux-headers-2.6.18.bsd40l-vz]====== This is kernel package version 10.067. echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 15m11.809s user 28m24.991s sys 5m47.362s real 15m58.245s user 28m37.815s sys 6m16.424s eyck@codev64:~/40m-ovz/work$ export CONCURRENCY_LEVEL=2 ... ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 21m25.527s user 27m58.473s sys 5m22.156s real 22m9.967s user 28m11.438s sys 5m51.326s eyck@etchdev386:~/40m-ovz/work$ export CONCURRENCY_LEVEL=6 ... echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 15m8.466s user 28m36.763s sys 6m10.971s real 15m52.911s user 28m49.976s sys 6m40.661s real 16m3.678s user 28m50.100s sys 6m44.369s eyck@etchdev386:~/40m-ovz/work$ export CONCURRENCY_LEVEL=8 echo done > stamp-kernel-headers ====== making target kernel_headers [new prereqs: stamp-configure stamp-prepare stamp-kernel-headers]====== This is kernel package version 10.067. real 17m56.831s user 28m18.070s sys 6m6.831s real 18m41.792s user 28m31.331s sys 6m36.289s real 18m53.592s user 28m31.447s sys 6m39.985s| Compiling kernels inside openvz | | 2007.11.01-02:43.00
Blacklist module - stop it from being loaded by modprobe/udev
echo "blacklist intel_agp" >> /etc/modprobe.d/blacklist
| Blacklist module - stop it from being loaded by modprobe/udev | | 2007.09.19-10:46.00
RaidF: FlashRaid - best solution for flash filesystems
- Divide your flash-based block device into >3 parts, for example let's use 12 sections.
- Raid5 (or Raid6 if you need more protection) them.
- use resulting block device as base for your filesystems/swap.
This way you can run without wear-levelling layer (which AFAIK can't work in general case, because you would need Size/blocksize bytes/nibbles of additional wear-resistant storage to keep statistics of your wear), AND you gain additional protection, for very little price ( less then 10% of your storage ).
Conventional wisdom says you shouldn't raid on single device, but since flash devices are not mechanical and don't suffer noticable seek penalty you can do this with very little loss of performance. If you'd do this in hardware inside your card, there would be no performance penalty.
Another problem is that raid5/raid6 are famouse for their poor write speed, but, since you're already writing whole blocks-at-a-time when dealing with flash devices, you're already paying the prices (writing block-at-a-time is the best case scenario for raid5/6, there's no need to recalculate checksums then)
- Effective protection for wear problems, plus additional protection for other block errors
- Very small price storage-wise (<10%)
- Very small performance penalty when you synchronise flash blocks with raid blocks (the penalty for writing less-then-block-at-a-time is already payed when dealing with flash, raid penalty is virtually non-existant then)
- Ideal for embedding in hardware, but doable on software-side
Note: it doesn't make much sense to use raid5 instead of raid4 in this case. And raid4e for double protection. TODO: implement RaidF as dm layer?
| RaidF: FlashRaid - best solution for flash filesystems | | 2007.09.09-22:26.00
Upgrade to LVM2 from LVM1 on running system
Problem:
homenode:/home/eyck# pvcreate /dev/cciss/c0d2p5 Physical volume "/dev/cciss/c0d2p5" successfully created homenode:/home/eyck# vgscan Reading all physical volumes. This may take a while... Found volume group "sys" using metadata type lvm1 homenode:/home/eyck# vgextend sys /dev/cciss/c0d2p5 Physical volume /dev/cciss/c0d2p5 is of different format type (lvm2) Unable to add physical volume '/dev/cciss/c0d2p5' to volume group 'sys'. homenode:/home/eyck# pvscan PV /dev/cciss/c0d0p3 VG sys lvm1 [66.34 GB / 0 free] PV /dev/cciss/c0d1p5 VG sys lvm1 [130.34 GB / 6.19 GB free] PV /dev/cciss/c0d2p5 lvm2 [33.91 GB] Total: 3 [230.60 GB] / in use: 2 [196.69 GB] / in no VG: 1 [33.91 GB]
Solution:
homenode:/home/eyck# vgconvert -M2 sys Volume group sys successfully converted homenode:/home/eyck# pvscan PV /dev/cciss/c0d0p3 VG sys lvm2 [66.34 GB / 0 free] PV /dev/cciss/c0d1p5 VG sys lvm2 [130.34 GB / 6.19 GB free] PV /dev/cciss/c0d2p5 lvm2 [33.91 GB] Total: 3 [230.60 GB] / in use: 2 [196.69 GB] / in no VG: 1 [33.91 GB] homenode:/home/eyck# vgextend sys /dev/cciss/c0d2p5 Volume group "sys" successfully extended homenode:/home/eyck# pvscan PV /dev/cciss/c0d0p3 VG sys lvm2 [66.34 GB / 0 free] PV /dev/cciss/c0d1p5 VG sys lvm2 [130.34 GB / 6.19 GB free] PV /dev/cciss/c0d2p5 VG sys lvm2 [33.91 GB / 33.91 GB free] Total: 3 [230.59 GB] / in use: 3 [230.59 GB] / in no VG: 0 [0 ] homenode:/home/eyck# lvextend -L+5G /dev/sys/v Extending logical volume v to 194.50 GB Logical volume v successfully resized homenode:/home/eyck# xfs_growfs /fs/v/ meta-data=/dev/sys/v isize=256 agcount=61, agsize=819200 blks = sectsz=512 attr=1 data = bsize=4096 blocks=49676288, imaxpct=25 = sunit=0 swidth=0 blks, unwritten=1 naming =version 2 bsize=4096 log =internal bsize=4096 blocks=6400, version=1 = sectsz=512 sunit=0 blks realtime =none extsz=65536 blocks=0, rtextents=0 data blocks changed from 49676288 to 50987008| Upgrade to LVM2 from LVM1 on running system | | 2007.09.06-12:48.00
Create Degraded Raid1
gnoll2:~# mdadm --create /dev/md1 --level 1 --raid-devices=2 missing /dev/hdh5 mdadm: array /dev/md1 started. gnoll2:~# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 hdh5[1] 77152064 blocks [2/1] [_U] unused devices: <none>gnoll2:/fs/tmp# mdadm --add /dev/md1 /dev/hde5 mdadm: added /dev/hde5 gnoll2:/fs/tmp# cat /proc/mdstat Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] md1 : active raid1 hde5[2] hdh5[1] 77152064 blocks [2/1] [_U] [>....................] recovery = 0.0% (18560/77152064) finish=414.6min speed=3093K/sec unused devices: <none> gnoll2:/fs/tmp#| Create Degraded Raid1 | | 2007.09.05-16:21.00
naviinittoolcli
./naviinittoolcli ... Navisphere Array Initialization Tool Version 6.24.0.6.7 # 17:10:54.728973 IP 10.11.12.231.35294 > 255.255.255.255.2162: UDP, length 71 # # 17:14:28.211377 IP 10.11.12.231.35294 > 255.255.255.255.2162: UDP, length 71 # 0x0000: 4500 0063 0000 4000 4011 bafa c0a8 bee7 E..c..@.@....... # 0x0010: ffff ffff 89de 0872 004f f516 3c54 3120 .......r.O..<T1. # 0x0020: 5433 3d22 5434 2220 5432 3d22 4154 4154 T3="T4".T2="ATAT # 0x0030: 5544 4522 2054 373d 2231 3237 2e30 2e30 UDE".T7="127.0.0 # 0x0040: 2e31 2220 5433 343d 2236 2e32 342e 3022 .1".T34="6.24.0" # 0x0050: 203e .> No storage systems discovered. Please verify the following items and try again. 1. The storage systems are powered up. 2. The storage systems are plugged in to the network. 3. This wizard is run on a client machine that is in the same physical subnet as the storage systems.
| naviinittoolcli | | 2007.08.27-14:41.00
Vserver and Xorg
(2.2.x) don't forget to procunhide /proc/bus/pci/ and /proc/bus in /etc/vservers/.defaults/apps/vprocunhide/files (create it based on /usr/lib/util-vserver/defaults/vprocunhide-files)| Vserver and Xorg | | 2007.08.04-08:35.00
Setting up Linux *SWAN Ipsec for nokia e61
Cached from: http://www.thorsten-knabe.de/linux/e61.jspConnecting the Nokia E61 Mobile VPN client to a Linux OpenSwan IPSEC gateway
This page describes how to configure and setup the Nokia E61 Mobile VPN client and Linux Openswan IPSEC gateway to establish an encrypted IPSEC tunnel between the two devices. The procedure described herein should work for other mobile devices equipped with a Nokia Mobile VPN Client as well, especially Symbian S60 3rd edition based mobile phones, but has not been tested.
Legal advice: This page contains links to external internet sites containing additional information, that might be helpful in the course of setting up the IPSEC tunnel. I have no influence on the content and disclaim any responsibilty for the content provided by those external internet sites.
All information on this page is provided as is without any warranty. I am not responsible or liable for any damage caused by following the steps described below. If you damage your phone, it is your fault not mine!Prerequisites
Linux prerequisites
For my setup I chose a vanilla Linux 2.6.19.1 with IPSEC support and OpenSwan 2.4.6 from Debian testing. Other kernels, distributions and OpenSwan versions could work as well but have not been tested.
E61 prerequisites
In oder to establish a VPN connection from the Nokia Mobile VPN client, a policy file has to be uploaded to the phone. For some reason, such a policy file cannot be uploaded directly to the phone, but has to be packed into a signed SIS file first. To create such a signed SIS file, you need a developer certificate and two Windows executables from the S60 Platform SDK for Symbian OS for C++ 3rd edition. Luckily those two Windows executables and the Windows executable to create the developer certificate run happily using Wine under Linux.
The S60 Platform SDK for Symbian OS for C++ 3rd edition is available from http://www.forum.nokia.com -> Tools & SDKs -> C++ for Symbian OS Tools and SDKs -> S60 Platform for Symbian OS -> 3rd Edition. To unpack the SDK under Linux follow the instructions on Rudolf Königs page.
A free developer cetificate and the Windows executable to create such a certificate is available from https://www.symbiansigned.com. Follow the steps on this site to obtain a valid developer certificate. Afterwards you should have a .key and a corresponding .cer file which are later required to sign the SIS file containing the VPN policy file.
Configuration
Before you start configuration, you should collect the following information, which are required during the configuration process. The actual values are replaced by the following placeholders in the example configuration files below:
<group name>: Group name for IKE phase 1. This value is ignored by the current OpenSwan configuration.
<group password>: Group password for IKE phase 1. Choose a good password for this parameter and keep it secret as it is the only thing needed to know to get access to your internal network if you do not use XAUTH authentication.
<strlen(group password)>: Length of group password
<external gateway>: External static IP address of the OpenSwan gateway. This address is used for authentication and encrypted data exchange.
<internal gateway>: Internal IP address of the OpenSwan gateway. This address is used when sending packets from the VPN gateway through the VPN tunnel to the client.
<internal client>: Internal IP address assigned to the VPN client. This address is used by the client when sending packets through the VPN tunnel.
<key password>: The password of your developer key from www.symbiansigned.com.
OpenSwan configuration
On Debian there are 3 files that have to be edited or created in order to configure OpenSwan as a VPN gateway for the Nokia Mobile VPN client.
/etc/ipsec.secrets
Add a wildcard PSK (Pre-Shared Key) entry to your ipsec.secrets file. Afterwards your ipsec.secrets file should look like this:
: PSK "<group password>"
/etc/ipsec.conf
Add an include directive to the ipsec.conf configuration file. The included file contains the actual configuration for the newly created connection to the Mobile VPN client. Afterwards your ipsec.conf should look like this:
version 2.0 config setup nat_traversal=yes nhelpers=0 #plutodebug=all # Add connections here #Disable Opportunistic Encryption include /etc/ipsec.d/examples/no_oe.conf include /etc/ipsec.d/examples/e61.conf/etc/ipsec.d/examples/e61.conf
Create a file named e61.conf for the connection parameters with the following contents:
conn E61 # Key exchange ike=aes256-sha1-modp1536 # Data exchange esp=aes256-sha1 # Authentication method PSK authby=secret auto=add keyingtries=3 rekey=no pfs=no # Modeconfig setting modecfgpull=yes # local endpoint left=<external gateway> leftxauthserver=yes leftmodecfgserver=yes leftsourceip=<internal gateway> leftsubnet=0.0.0.0/0 # remote endpoint right=%any rightxauthclient=yes rightmodecfgclient=yes rightsourceip=<internal client> rightsubnet=<internal client>/32If you set leftxauthserver and rightxauthclient to no, XAUTH authentication will be disabled. Disabling XAUTH authentication might be helpful, if you experience problems during VPN setup, but should not be disabled in production use for security reasons.
Creating a signed SIS file containing the VPN policy
The Nokia Mobile VPN client is configured by the policy file VPN.pol shown below, that has to be uploaded to the phone in a signed SIS file.
In order to create a signed SIS file, two additional files are required. The VPN.pin file contains some (useless) meta information about the policy file, but is required and the VPN.pkg file, which describes the contents of the SIS file. Important: All 3 files have to be created with DOS line delimiters (in vi use: set ff=dos), otherwise the tools or the VPN will not work correctly.
VPN.pol
SECURITY_FILE_VERSION: 3 [INFO] VPN [POLICY] sa ipsec_1 = { esp encrypt_alg 12 max_encrypt_bits 256 auth_alg 3 identity_remote 0.0.0.0/0 src_specific hard_lifetime_bytes 0 hard_lifetime_addtime 3600 hard_lifetime_usetime 3600 soft_lifetime_bytes 0 soft_lifetime_addtime 3600 soft_lifetime_usetime 3600 } remote 0.0.0.0 0.0.0.0 = { ipsec_1(<external gateway>) } inbound = { } outbound = { } [IKE] ADDR: <external gateway> 255.255.255.255 MODE: MAIN SEND_NOTIFICATION: TRUE ID_TYPE: 11 FQDN: <group name> GROUP_DESCRIPTION_II: MODP_1536 USE_COMMIT: FALSE IPSEC_EXPIRE: FALSE SEND_CERT: FALSE INITIAL_CONTACT: FALSE RESPONDER_LIFETIME: TRUE REPLAY_STATUS: TRUE USE_INTERNAL_ADDR: FALSE USE_NAT_PROBE: FALSE ESP_UDP_PORT: 0 NAT_KEEPALIVE: 60 USE_XAUTH: TRUE USE_MODE_CFG: TRUE REKEYING_THRESHOLD: 90 PROPOSALS: 1 ENC_ALG: AES256-CBC AUTH_METHOD: PRE-SHARED HASH_ALG: SHA1 GROUP_DESCRIPTION: MODP_1536 GROUP_TYPE: DEFAULT LIFETIME_KBYTES: 0 LIFETIME_SECONDS: 28800 PRF: NONE PRESHARED_KEYS: FORMAT: STRING_FORMAT KEY: <strlen(group password)> <group password>If you want to disable XAUTH authentication set USE_XAUTH to FALSE and modify the e61.conf file on the VPN gateway accordingly.
VPN.pin
[POLICYNAME] VPN [POLICYDESCRIPTION] VPN [POLICYVERSION] 1.1 [ISSUERNAME] Do not edit [CONTACTINFO] Do not edit
VPN.pkg
; ; A VPN POLICY PACKAGE ; %{"VPN"} :"VPN" &EN ; - None (English only by default) ; INSTALLATION HEADER ; - Only one component name is needed to support English only ; - UID is the UID of the VPN Policy Installer application #{"VPN"},(0x3D08B4F7),1,0,0,TYPE = SA ; LIST OF FILES ; Policy file "VPN.pol"-"C:\System\Data\Security\Install\VPN.pol" ; Policy-information file ; - NOTE: The policy-information file MUST be the last file in this ; list! ; - FM (FILEMIME) passes the file to the respective MIME handler ; (in this case, the VPN Policy Installer ; application). "VPN.pin"-"C:\System\Data\Security\Install\VPN.pin", FM, "application/x-ipsec-policy-info" ; REQUIRED FILES ; - The VPN Policy Installer application (0x3D08B4F7), 1, 0, 0, {"VPN Policy Installer"}Note: The two absolute paths are paths on the phone and must not be modified.
Create an unsigned SIS file
The unsigned SIS file is created by the makesis.exe utility. With the VPN.pol, VPN.pin and VPN.pkg file in the current working directory the makesis utility must be invoked as follows:
makesis.exe VPN.pkg VPN.sis
Afterwards you should have a VPN.sis file in your current working directory.
Create a signed SIS file
The SIS file created in the last step is still unsigned and has to be signed to be accepted by the phone. The SIS file is signed using the signsis.exe utility. It is invoked as follows, assuming the previously created SIS file and the VPN.key and VPN.cer file from www.symbiansigned.com are all located in the current working directory:
signsis.exe VPN.sis VPN.sisx VPN.cer VPN.key <key password>
Afterwards you should have a signed SIS file called VPN.sisx in your current working directory, which can be uploaded to your phone.
Mobile phone configuration
Before you start configuring the Nokia Mobile VPN client, you have to upload the signed SIS file created in the previous step to the phone. This can be done using an USB cable, infrared or Bluetooth or you can download the file from a web site. During installation of the policy file, you might get several warnings regarding the developer cerificate and phone incompatibilities, ignore and confirm all of them. After the installation completes the policy should be listed under VPN policies in the phone.
To create a new VPN connection configuration navigate to Menu -> Tools -> Settings -> Connection -> VPN -> VPN management -> VPN policies, highlight a policy and select Options -> Define VPN access point. Configure the connection by specifiying a name, a policy and an internet access point.
You should now be able to use the VPN connection like any other connection. If you have not disabled XAUTH authentication, you are asked for a username and password on connection setup. Enter a valid system user and password of the VPN gateway. That's it! You should now be connected to your VPN.
Caveats & Solutions
DNS servers
During connection setup the VPN client obtains IP address, netmask and DNS settings from the VPN gateway, there is no way to modify those parameters on the phone.
In OpenSwan 2.4.6 there is no (easy) way to configure the DNS servers to be used by the VPN client. DNS servers can only be set using PAM environment variables, which are only available when XAUTH is enabled.To circumvent this shortcoming I have created a small patch against OpenSwan 2.4.6, which allows setting DNS servers using ordinary environment variables. If you set the environment variables DNS1 and DNS2 before you start OpenSwan, those parameters are transmitted to the VPN client as the primary and secondary DNS server. The patch is available here: openswan-2.4.6.diff
| Setting up Linux *SWAN Ipsec for nokia e61 | | 2007.06.27-09:21.00
Connecting the Nokia E61 Mobile VPN client to a Linux OpenSwan IPSEC gateway This page describes how to configure and setup the Nokia E61 Mobile VPN client and Linux Openswan IPSEC gateway to establish an encrypted IPSEC tunnel between the two devices. The procedure described herein should work for other mobile devices equipped with a Nokia Mobile VPN Client as well, especially Symbian S60 3rd edition based mobile phones, but has not been tested. Legal advice: This page contains links to external internet sites containing additional information, that might be helpful in the course of setting up the IPSEC tunnel. I have no influence on the content and disclaim any responsibilty for the content provided by those external internet sites. All information on this page is provided as is without any warranty. I am not responsible or liable for any damage caused by following the steps described below. If you damage your phone, it is your fault not mine! Prerequisites Linux prerequisites For my setup I chose a vanilla Linux 2.6.19.1 with IPSEC support and OpenSwan 2.4.6 from Debian testing. Other kernels, distributions and OpenSwan versions could work as well but have not been tested. E61 prerequisites In oder to establish a VPN connection from the Nokia Mobile VPN client, a policy file has to be uploaded to the phone. For some reason, such a policy file cannot be uploaded directly to the phone, but has to be packed into a signed SIS file first. To create such a signed SIS file, you need a developer certificate and two Windows executables from the S60 Platform SDK for Symbian OS for C++ 3rd edition. Luckily those two Windows executables and the Windows executable to create the developer certificate run happily using Wine under Linux. The S60 Platform SDK for Symbian OS for C++ 3rd edition is available from http://www.forum.nokia.com -> Tools & SDKs -> C++ for Symbian OS Tools and SDKs -> S60 Platform for Symbian OS -> 3rd Edition. To unpack the SDK under Linux follow the instructions on Rudolf Königs page. A free developer cetificate and the Windows executable to create such a certificate is available from https://www.symbiansigned.com. Follow the steps on this site to obtain a valid developer certificate. Afterwards you should have a .key and a corresponding .cer file which are later required to sign the SIS file containing the VPN policy file. Configuration Before you start configuration, you should collect the following information, which are required during the configuration process. The actual values are replaced by the following placeholders in the example configuration files below:: Group name for IKE phase 1. This value is ignored by the current OpenSwan configuration. : Group password for IKE phase 1. Choose a good password for this parameter and keep it secret as it is the only thing needed to know to get access to your internal network if you do not use XAUTH authentication. : External static IP address of the OpenSwan gateway. This address is used for authentication and encrypted data exchange. : Internal IP address of the OpenSwan gateway. This address is used when sending packets from the VPN gateway through the VPN tunnel to the client. : Internal IP address assigned to the VPN client. This address is used by the client when sending packets through the VPN tunnel. : The password of your developer key from www.symbiansigned.com. OpenSwan configuration On Debian there are 3 files that have to be edited or created in order to configure OpenSwan as a VPN gateway for the Nokia Mobile VPN client. /etc/ipsec.secrets Add a wildcard PSK (Pre-Shared Key) entry to your ipsec.secrets file. Afterwards your ipsec.secrets file should look like this: : PSK " " /etc/ipsec.conf Add an include directive to the ipsec.conf configuration file. The included file contains the actual configuration for the newly created connection to the Mobile VPN client. Afterwards your ipsec.conf should look like this: version 2.0 config setup nat_traversal=yes nhelpers=0 #plutodebug=all # Add connections here #Disable Opportunistic Encryption include /etc/ipsec.d/examples/no_oe.conf include /etc/ipsec.d/examples/e61.conf /etc/ipsec.d/examples/e61.conf Create a file named e61.conf for the connection parameters with the following contents: conn E61 # Key exchange ike=aes256-sha1-modp1536 # Data exchange esp=aes256-sha1 # Authentication method PSK authby=secret auto=add keyingtries=3 rekey=no pfs=no # Modeconfig setting modecfgpull=yes # local endpoint left= leftxauthserver=yes leftmodecfgserver=yes leftsourceip= leftsubnet=0.0.0.0/0 # remote endpoint right=%any rightxauthclient=yes rightmodecfgclient=yes rightsourceip= rightsubnet= /32 If you set leftxauthserver and rightxauthclient to no, XAUTH authentication will be disabled. Disabling XAUTH authentication might be helpful, if you experience problems during VPN setup, but should not be disabled in production use for security reasons. Creating a signed SIS file containing the VPN policy The Nokia Mobile VPN client is configured by the policy file VPN.pol shown below, that has to be uploaded to the phone in a signed SIS file. In order to create a signed SIS file, two additional files are required. The VPN.pin file contains some (useless) meta information about the policy file, but is required and the VPN.pkg file, which describes the contents of the SIS file. Important: All 3 files have to be created with DOS line delimiters (in vi use: set ff=dos), otherwise the tools or the VPN will not work correctly. VPN.pol SECURITY_FILE_VERSION: 3 [INFO] VPN [POLICY] sa ipsec_1 = { esp encrypt_alg 12 max_encrypt_bits 256 auth_alg 3 identity_remote 0.0.0.0/0 src_specific hard_lifetime_bytes 0 hard_lifetime_addtime 3600 hard_lifetime_usetime 3600 soft_lifetime_bytes 0 soft_lifetime_addtime 3600 soft_lifetime_usetime 3600 } remote 0.0.0.0 0.0.0.0 = { ipsec_1( ) } inbound = { } outbound = { } [IKE] ADDR: 255.255.255.255 MODE: MAIN SEND_NOTIFICATION: TRUE ID_TYPE: 11 FQDN: GROUP_DESCRIPTION_II: MODP_1536 USE_COMMIT: FALSE IPSEC_EXPIRE: FALSE SEND_CERT: FALSE INITIAL_CONTACT: FALSE RESPONDER_LIFETIME: TRUE REPLAY_STATUS: TRUE USE_INTERNAL_ADDR: FALSE USE_NAT_PROBE: FALSE ESP_UDP_PORT: 0 NAT_KEEPALIVE: 60 USE_XAUTH: TRUE USE_MODE_CFG: TRUE REKEYING_THRESHOLD: 90 PROPOSALS: 1 ENC_ALG: AES256-CBC AUTH_METHOD: PRE-SHARED HASH_ALG: SHA1 GROUP_DESCRIPTION: MODP_1536 GROUP_TYPE: DEFAULT LIFETIME_KBYTES: 0 LIFETIME_SECONDS: 28800 PRF: NONE PRESHARED_KEYS: FORMAT: STRING_FORMAT KEY: If you want to disable XAUTH authentication set USE_XAUTH to FALSE and modify the e61.conf file on the VPN gateway accordingly. VPN.pin [POLICYNAME] VPN [POLICYDESCRIPTION] VPN [POLICYVERSION] 1.1 [ISSUERNAME] Do not edit [CONTACTINFO] Do not edit VPN.pkg ; ; A VPN POLICY PACKAGE ; %{"VPN"} :"VPN" &EN ; - None (English only by default) ; INSTALLATION HEADER ; - Only one component name is needed to support English only ; - UID is the UID of the VPN Policy Installer application #{"VPN"},(0x3D08B4F7),1,0,0,TYPE = SA ; LIST OF FILES ; Policy file "VPN.pol"-"C:\System\Data\Security\Install\VPN.pol" ; Policy-information file ; - NOTE: The policy-information file MUST be the last file in this ; list! ; - FM (FILEMIME) passes the file to the respective MIME handler ; (in this case, the VPN Policy Installer ; application). "VPN.pin"-"C:\System\Data\Security\Install\VPN.pin", FM, "application/x-ipsec-policy-info" ; REQUIRED FILES ; - The VPN Policy Installer application (0x3D08B4F7), 1, 0, 0, {"VPN Policy Installer"} Note: The two absolute paths are paths on the phone and must not be modified. Create an unsigned SIS file The unsigned SIS file is created by the makesis.exe utility. With the VPN.pol, VPN.pin and VPN.pkg file in the current working directory the makesis utility must be invoked as follows: makesis.exe VPN.pkg VPN.sis Afterwards you should have a VPN.sis file in your current working directory. Create a signed SIS file The SIS file created in the last step is still unsigned and has to be signed to be accepted by the phone. The SIS file is signed using the signsis.exe utility. It is invoked as follows, assuming the previously created SIS file and the VPN.key and VPN.cer file from www.symbiansigned.com are all located in the current working directory: signsis.exe VPN.sis VPN.sisx VPN.cer VPN.key Afterwards you should have a signed SIS file called VPN.sisx in your current working directory, which can be uploaded to your phone. Mobile phone configuration Before you start configuring the Nokia Mobile VPN client, you have to upload the signed SIS file created in the previous step to the phone. This can be done using an USB cable, infrared or Bluetooth or you can download the file from a web site. During installation of the policy file, you might get several warnings regarding the developer cerificate and phone incompatibilities, ignore and confirm all of them. After the installation completes the policy should be listed under VPN policies in the phone. To create a new VPN connection configuration navigate to Menu -> Tools -> Settings -> Connection -> VPN -> VPN management -> VPN policies, highlight a policy and select Options -> Define VPN access point. Configure the connection by specifiying a name, a policy and an internet access point. You should now be able to use the VPN connection like any other connection. If you have not disabled XAUTH authentication, you are asked for a username and password on connection setup. Enter a valid system user and password of the VPN gateway. That's it! You should now be connected to your VPN. Caveats & Solutions DNS servers During connection setup the VPN client obtains IP address, netmask and DNS settings from the VPN gateway, there is no way to modify those parameters on the phone. In OpenSwan 2.4.6 there is no (easy) way to configure the DNS servers to be used by the VPN client. DNS servers can only be set using PAM environment variables, which are only available when XAUTH is enabled. To circumvent this shortcoming I have created a small patch against OpenSwan 2.4.6, which allows setting DNS servers using ordinary environment variables. If you set the environment variables DNS1 and DNS2 before you start OpenSwan, those parameters are transmitted to the VPN client as the primary and secondary DNS server. The patch is available here: openswan-2.4.6.diff _____________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________________ Back 2356 visitors Imprint | | | 2007.06.27-09:19.00
apt-get: Floating point exception
sid: ~# apt-get update Floating point exception
Culprit: gcc 4.1.2 runtime (gcc-4.1-base libgcc and libstdc++ )sid: ~# dpkg -i /var/cache/apt/archives/libstdc++6_4.1.1-21_i386.deb dpkg - warning: downgrading libstdc++6 from 4.1.2-5 to 4.1.1-21. (Reading database ... 17076 files and directories currently installed.) Preparing to replace libstdc++6 4.1.2-5 (using .../libstdc++6_4.1.1-21_i386.deb) ... Unpacking replacement libstdc++6 ... Setting up libstdc++6 (4.1.1-21) ... sid: ~# apt-get upgrade Reading package lists... Done Building dependency tree... Done
| apt-get: Floating point exception | | 2007.05.15-08:11.00
mount /dev/s/usr U && mv usr/* U/ && umount U && mount /dev/s/usr /usr && grep usr /etc/mtab >> /etc/fstab mount /dev/s/var V && mv var/* V/ && umount V && mount /dev/s/var /var && grep var /etc/mtab >> /etc/fstab| | | 2007.04.08-23:43.00
1) rmmod is missing 2) cfdisk is missing 3) ping is missing 4) tcpdump is missing 5) less is missing| | | 2007.04.08-21:01.00
Display
RemoteDisplay.vnc.enabled = TRUE RemoteDisplay.vnc.port = 5901 RemoteDisplay.vnc.password = 12345678| Display | | 2007.02.08-21:56.00
- Boot with `profile=1' on the kernel command line sudo readprofile -r sudo readprofile -M10 timereadprofile -n -v -m /boot/System.map | sort -n +2 | tail -40 | tee ~/log | | | 2007.01.06-23:40.00
The only place where the large route cache seems to make sense is for larger servers that are servicing internet connections from many sites. Since the cache is completely flushed every 10 minutes by default, the above machine would have to be adding 55,924 routes per second that were ideally distrbuted throughout the hash space to even fill every bucket. The patch I am proposing is as follows. For the sites that need larger route hashes, they can use the rhash_entries command line option to set it as desired. (http://lkml.org/lkml/2004/12/9/92) gc_elesticity can best be described as the average bucket depth the kernel will accept before it starts expiring route hash entries. This will help maintain the upper limit of active routes. echo 8 > /proc/sys/net/ipv4/route/gc_elasticity (http://lwn.net/Articles/145406/) gc_thresh is another limiting factor in controlling how much RAM your policy routing will eat up. This number cannot be greater than the rhash_entries kernel parameter. As a rule of thumb, set your rhash_entries parameter REALLY high(mine is 2.4million) and control your running limit with gc_thresh. echo 1048576 > /proc/sys/net/ipv4/route/gc_thresh (http://lwn.net/Articles/145406/) IN:Hits are cache hits yes? Tot, are the total number of flows created since we last looked at the total flow count, correct? What would cause a packet to drop in the network stack and thus showup in /proc/net/softnet_stat?| | | 2007.01.06-20:36.00
/proc/net/softnet_stat
total droppped tsquz Throttl FR_hit FR_succe FR_defer FR_def_o cpu_coll 00379350 00000000 00000032 00000000 00000000 00000000 00000000 00000000 0000576c 23aa79eb 000045db 009d960c 00000000 00000000 00000000 00000000 00000000 00028a73 00bc9ef3 00000000 000123ab 00000000 00000000 00000000 00000000 00000000 0000896d 005f5298 00000000 0000002b 00000000 00000000 00000000 00000000 00000000 00004b61 00387deb 00000000 00000037 00000000 00000000 00000000 00000000 00000000 00008d0b 2c12916a 00000000 0000270a 00000000 00000000 00000000 00000000 00000000 0001ab8f ^ duzo dropped on eth1| /proc/net/softnet_stat | | 2007.01.06-19:02.00
