-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathatom.xml
403 lines (275 loc) · 23.2 KB
/
atom.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
<title><![CDATA[Advenatures in computing]]></title>
<link href="http://jowrjowr.github.io/atom.xml" rel="self"/>
<link href="http://jowrjowr.github.io/"/>
<updated>2014-11-14T01:58:03-06:00</updated>
<id>http://jowrjowr.github.io/</id>
<author>
<name><![CDATA[Eric Gisse]]></name>
</author>
<generator uri="http://octopress.org/">Octopress</generator>
<entry>
<title type="html"><![CDATA[Time Matters]]></title>
<link href="http://jowrjowr.github.io/blog/2014/11/14/time-matters/"/>
<updated>2014-11-14T01:40:32-06:00</updated>
<id>http://jowrjowr.github.io/blog/2014/11/14/time-matters</id>
<content type="html"><![CDATA[<p>…no, not time in the philosophical or project management sense. Well yes, but not what this is about.</p>
<p>In tracking an issue on a client project, a curious issue was ran into.</p>
<p>Basically, the setup is such that we have a cluster of machines. One machine in the cluster farms out work to the rest of it, the cluster does the work, writes the result to NFS, and the machine that farms out the work snags the result.</p>
<p>Except this was breaking, and we couldn’t figure out why.</p>
<pre><code>2014-11-12T15:03:46.247Z - debug: JOB FINISHED job_8l5pmjvp
2014-11-12T15:03:46.248Z - debug: try to delete job_8l5pmjvp masterJob undefined read from fs
2014-11-12T15:03:46.248Z - debug: deleting job
2014-11-12T15:03:46.554Z - debug: ERROR@read attempt | after redis signaled the job is ready job_0i5imjsd attempt no: 10 ENOENT
2014-11-12T15:03:47.053Z - debug: ERROR@read attempt | after redis signaled the job is ready job_0i5imjsd attempt no: 11 ENOENT
2014-11-12T15:03:47.053Z - error: ERROR@readFile job_0i5imjsd | number of attempts: 11 http://www.esquire.com/women/women-we-love/kate-mara-naked-0309 j/3/r/c/6/d1u78w1u5wqqexvq5tjq6wbnd5t6abk3dxpjyxvfdnjpwbvqdxppavhdexjjuv3fetjjyuv1ehjjuvb1e9gjuvk1ddjp8b9g6cr3j_hq.png ENOENT /mnt/images/j/3/r/c/6/d1u78w1u5wqqexvq5tjq6wbnd5t6abk3dxpjyxvfdnjpwbvqdxppavhdexjjuv3fetjjyuv1ehjjuvb1e9gjuvk1ddjp8b9g6cr3j_hq.png
</code></pre>
<p>Translated: at 15:03:47.053, the machine that wanted to find the file could not find it.</p>
<p>But the file system says this:</p>
<pre><code># stat /mnt/images/j/3/r/c/6/d1u78w1u5wqqexvq5tjq6wbnd5t6abk3dxpjyxvfdnjpwbvqdxppavhdexjjuv3fetjjyuv1ehjjuvb1e9gjuvk1ddjp8b9g6cr3j_hq.png
File: /mnt/images/j/3/r/c/6/d1u78w1u5wqqexvq5tjq6wbnd5t6abk3dxpjyxvfdnjpwbvqdxppavhdexjjuv3fetjjyuv1ehjjuvb1e9gjuvk1ddjp8b9g6cr3j_hq.png
Size: 134775 Blocks: 264 IO Block: 1048576 regular file
Device: 23h/35d Inode: 80478457 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 99/ nobody) Gid: ( 99/ nobody)
Context: system_u:object_r:nfs_t:s0
Access: 2014-11-12 15:09:49.215002251 +0000
Modify: 2014-11-12 15:09:49.239002078 +0000
Change: 2014-11-12 15:09:49.239002078 +0000
Birth: -
</code></pre>
<p>A careful observer will note that the file that was supposedly not missing was written two seconds <strong><em>after</em></strong>. This lead me to believe that there was an issue with timing in the code, and we went down that path.</p>
<p>It was then discovered that the NFS server that hosts this data wasn’t running NTP and was thus out of sync. The one machine in the cluster that <em>wasn’t</em> under puppet control. My forcing of ntp is so common I didn’t even consider the possibility that time could have been an issue.</p>
<p>Once time was synchronized, the script was flipped.</p>
<p>Instead of the “missing” file being written after the script stopped looking, it was written <em>before</em>. Given the close timings and how the issue wasn’t reliably predictable I felt it was some sort of race condition between the two cluster nodes.</p>
<p>It turns out I was right, after a fashion.</p>
<p>Myself and this client have <em>not</em> had a good history with network file systems. CephFS was a saga, for example. So we switched over to NFS which is a (nominally) stable and known solution.</p>
<p>So after investigating, I discover this little blurb in an nfs man page:</p>
<blockquote><p>To improve performance, NFS clients cache file attributes. Every few seconds, an NFS client checks the server’s version of each file’s attributes for updates. Changes that occur on the server in those small intervals remain undetected until the client checks the server again. The noac option prevents clients from caching file attributes so that applications can more quickly detect file changes on the server.</p>
<p>In addition to preventing the client from caching file attributes, the noac option forces application writes to become synchronous so that local changes to a file become visible on the server immediately. That way, other clients can quickly detect recent writes when they check the file’s attributes.</p>
<p>Using the noac option provides greater cache coherence among NFS clients accessing the same files, but it extracts a significant performance penalty. As such, judicious use of file locking is encouraged instead. The DATA AND METADATA COHERENCE section contains a detailed discussion of these trade-offs.</p>
<p><a href="http://linux.die.net/man/5/nfs">http://linux.die.net/man/5/nfs</a></p></blockquote>
<p>It turns out that an NFS client caches file attributes in a folder, which extends to whether a file <em>actually exists</em>. Surprisingly not once in quite a few years of battling NFS has this ever come up.</p>
<p>The moral of the story here isn’t (just) that networked file systems can be hard, but that it is super important to make sure that your servers times are synchronized. Because if they aren’t, you can find yourself looking down an <em>entirely wrong</em> troubleshooting path.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Adventures With PaX]]></title>
<link href="http://jowrjowr.github.io/blog/2014/11/06/adventures-with-pax/"/>
<updated>2014-11-06T19:00:21-06:00</updated>
<id>http://jowrjowr.github.io/blog/2014/11/06/adventures-with-pax</id>
<content type="html"><![CDATA[<p>As a part of running an exit node and wanting to experiment more with Linux hardening, I built out a nice Gentoo hardened-sources (3.16.5) kernel.</p>
<p>This has not been an issue for me as I’ve used grsecurity features for years. But the new system had some <em>crazy</em> instability. It resulted in miscellaneous kernel panics like this:</p>
<pre><code>Oct 27 09:52:53 REDACTED [23041.341354] general protection fault: 0000 [#4]
Oct 27 09:52:53 REDACTED SMP
Oct 27 09:52:53 REDACTED
Oct 27 09:52:53 REDACTED [23041.341413] Modules linked in:
Oct 27 09:52:53 REDACTED xt_DELUDE(O)
Oct 27 09:52:53 REDACTED xt_CHAOS(O)
Oct 27 09:52:53 REDACTED xt_TARPIT(O)
Oct 27 09:52:53 REDACTED
Oct 27 09:52:53 REDACTED [23041.341476] CPU: 6 PID: 3052 Comm: tor Tainted: G D O 3.17.1-hardened #1
Oct 27 09:52:53 REDACTED [23041.341538] Hardware name: Supermicro A1SA2-2750F/A1SA2-2750F, BIOS 1.0a 07/14/2014
Oct 27 09:52:53 REDACTED [23041.341600] task: ffff880276ed6b10 ti: ffff880276ed6f60 task.ti: ffff880276ed6f60
Oct 27 09:52:53 REDACTED [23041.341660] RIP: 0010:[<ffffffff814b58ce>]
Oct 27 09:52:53 REDACTED [<ffffffff814b58ce>] __nf_conntrack_find_get+0x6e/0x290
Oct 27 09:52:53 REDACTED [23041.341732] RSP: 0018:ffffc90006073930 EFLAGS: 00010246
Oct 27 09:52:53 REDACTED [23041.341770] RAX: 0000000000014230 RBX: fefefefefefefefe RCX: 0000000000014a70
Oct 27 09:52:53 REDACTED [23041.341811] RDX: 000000000000294e RSI: 00000000000266e2 RDI: 00000000fefefefe
Oct 27 09:52:53 REDACTED [23041.341852] RBP: ffffc90006073958 R08: 0000000073a1bccf R09: 00000000bd127271
Oct 27 09:52:53 REDACTED [23041.341894] R10: ffffc900060739c0 R11: ffff880273943f08 R12: ffffc900060739a8
Oct 27 09:52:53 REDACTED [23041.341935] R13: 0000000000000000 R14: 00000000a538c88a R15: ffffffff81a7e240
Oct 27 09:52:53 REDACTED [23041.341976] FS: 0000031cb9d65700(0000) GS:ffff88027fd80000(0000) knlGS:0000000000000000
Oct 27 09:52:53 REDACTED [23041.342037] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
Oct 27 09:52:53 REDACTED [23041.342077] CR2: 000002faa3f38000 CR3: 0000000001654000 CR4: 00000000001007f0
Oct 27 09:52:53 REDACTED [23041.342117] Stack:
Oct 27 09:52:53 REDACTED [23041.342147] ffff880211a540e0
</code></pre>
<p>While I am many things, I am not a skilled kernel hacker so the best I can do on my own is to figure out something is going on in the netfilter subsystem.</p>
<p>I then proceed to ask the grsecurity folks if they know what the fuck is going on: <a href="https://forums.grsecurity.net/viewtopic.php?f=1&t=4071&e=0">https://forums.grsecurity.net/viewtopic.php?f=1&t=4071&e=0</a></p>
<p>After some discussion between myself and the grsec folks, then myself <a href="http://marc.info/?l=netfilter-devel&m=141476930929914&w=2">and then the netfilter folks</a> it turns out this was an issue with a hip-pocket feature of PaX called PAX_MEMORY_SANITIZE:</p>
<blockquote><p>By saying Y here the kernel will erase memory pages and slab objects
as soon as they are freed. This in turn reduces the lifetime of data
stored in them, making it less likely that sensitive information such
as passwords, cryptographic secrets, etc stay in memory for too long.</p>
<p>See: <a href="https://en.wikibooks.org/wiki/Grsecurity/Appendix/Grsecurity_and_PaX_Configuration_Options#Sanitize_all_freed_memory">grsecurity wiki</a></p></blockquote>
<p>Apparently the memory sanitization was wiping an entry in the netfilter hash table, which contains the list of things used by iptables’ connection tracking feature. The problem came in when the wiping was done on an entry that was not fully yet marked as freed.</p>
<p>This appears to be a bit of a race condition that only infrequently (in an absolute sense - once every few hundred million conntrack entries) but that occurs quickly on a busy machine like mine.</p>
<p>The grsecurity/PaX folks have this fixed now, and seems to have resulted in fixing some other misc. issues folks were seeing. Yay!</p>
<p>I even filed a hardened kernel <a href="https://bugs.gentoo.org/show_bug.cgi?id=527668">bug report</a> for grins.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Gentoo and SELinux]]></title>
<link href="http://jowrjowr.github.io/blog/2014/10/23/gentoo-and-selinux/"/>
<updated>2014-10-23T08:22:13-05:00</updated>
<id>http://jowrjowr.github.io/blog/2014/10/23/gentoo-and-selinux</id>
<content type="html"><![CDATA[<p>So one of my personal projects is a 15 EUR/mo online.net tor exit node where I can tinker with puppet, selinux, gentoo, tor, security related thingies, and anything else that strikes my whim.</p>
<h3>Oh shit</h3>
<p>The problem is that SELinux is <em>hard</em>. Even in the optimal situation of doing this with RHEL, its’ a brittle little nightmare that doesn’t function for <em>beans</em> outside of the RHEL dotted line of what Redhat wants you to do. Which is rarely what <em>I</em> want to do.</p>
<p>So I’m using this as a process to teach myself how to properly make all of this shit work together. There is a <em>lot</em> to be written. For some reason.</p>
<h3>Bugs, pains in the ass, and gripes <em>already</em>?</h3>
<p><strong>Yep</strong>.</p>
<p>Here’s what I’ve ran into thus far, and how I’m combating it:</p>
<h2>1. irqbalance</h2>
<p>Having irqbalance is semi-important due to spreading network and other cpu interrupts across a multicore system rather than splashing them on CPU 0 all the time.</p>
<p>Unfortunately it doesn’t work by default out of the box without a little bit of tinkering (manually installing the irqbalance selinux policy).</p>
<p>Gentoo bug report <a href="https://bugs.gentoo.org/show_bug.cgi?id=525724">filed</a></p>
<h2>2. Management issues</h2>
<p>When you login (as root) by default, you get a user context of the following:</p>
<pre><code># id -Z
root:staff_r:staff_t
</code></pre>
<p>The problem is that the staff_t context isn’t sufficient for a lot of things. Mostly relating to init scripts and package installation.</p>
<p>For example, if you try to install a random package via emerge in the staff_t role you get this confusing heap of crap:</p>
<pre><code># emerge ntp
Calculating dependencies... done!
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) net-misc/ntp-4.2.6_p5-r11::gentoo
* ntp-4.2.6p5.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ...
[ ok ]
* ntp-4.2.6p5-manpages.tar.bz2 SHA256 SHA512 WHIRLPOOL size ;-) ...
[ ok ]
[Errno 22] Invalid argument:
/usr/bin/sandbox /usr/lib/portage/python2.7/ebuild.sh unpack
Traceback (most recent call last):
File "/usr/lib64/python2.7/site-packages/portage/process.py", line 317, in spawn
unshare_net, unshare_ipc, cgroup)
File "/usr/lib64/python2.7/site-packages/portage/process.py", line 512, in _exec
pre_exec()
File "/usr/lib64/python2.7/site-packages/portage/_selinux.py", line 119, in _pre_exec
setexec(self._con)
File "/usr/lib64/python2.7/site-packages/portage/_selinux.py", line 80, in setexec
if selinux.setexeccon(ctx) < 0:
OSError: [Errno 22] Invalid argument
</code></pre>
<p>Only after a lot (a little bit) of research do you learn that the error message is a result of the fact you need to have the sysadm_r role. If you pivot over with the following command, you are <em>golden</em>:</p>
<pre><code># id -Z
root:staff_r:staff_t
# newrole -r sysadm_r
Password:
# id -Z
root:sysadm_r:sysadm_t
</code></pre>
<p>This will let you install packages and stuff. And restart vixie-cron.</p>
<p><strong><em>Huh, cron?</em></strong></p>
<p>If you restart vixie-cron via the staff_r role, cron will run via the staff_r role:</p>
<pre><code># ps auxZ | grep cron
root:staff_r:staff_t root 11204 0.0 0.0 23484 2236 ? Ss 13:39 0:00 /usr/sbin/cron
</code></pre>
<p>This results in all sorts of confusing stuff:</p>
<pre><code># tail /var/log/cron.log
Oct 23 13:39:58 testbed cron[11204]: (CRON) STARTUP (V5.0)
Oct 23 13:39:58 testbed cron[11204]: (system_u) NO CONTEXT (/etc/crontab)
Oct 23 13:39:58 testbed cron[11204]: (munin) NO CONTEXT (crontabs/munin)
Oct 23 13:39:58 testbed cron[11204]: (root) ENTRYPOINT FAILED (crontabs/root)
</code></pre>
<p>You’ll waste <em>a lot</em> of time figuring out why /etc/crontab has the wrong selinux permissions.</p>
<p>The simple answer is to make sure vixie-cron runs under sysadm_r so it can transition properly to system_r:</p>
<pre><code># ps auxZ | grep cron
system_u:system_r:crond_t root 11322 0.0 0.0 23484 2220 ? Ss 13:42 0:00 /usr/sbin/cron
</code></pre>
<p>I have filed <a href="https://bugs.gentoo.org/show_bug.cgi?id=525726">a bug</a> on the portage issue to hopefully make things a bit more clear, as things are hard enough without cryptic shit being thrown at you.</p>
<h2>3. munin</h2>
<p>This is an ongoing nuisance, and is <em>already</em> running into some serious issues.</p>
<p>When you build munin with USE=“cron” or build the cron entry direct via a puppet cron resource, you’ll get this cryptic-as-fuck error message from cron:</p>
<pre><code>Oct 22 22:08:39 testbed cron[29465]: (CRON) STARTUP (V5.0)
Oct 22 22:08:39 testbed cron[29465]: (munin) ENTRYPOINT FAILED (crontabs/munin)
</code></pre>
<p><em>“What the fuck?”</em> is exactly what I settled on as a response, given it had (ostensibly) the proper contexts and all that:</p>
<pre><code># ls -Z /var/spool/cron/crontabs/munin
root:object_r:user_cron_spool_t /var/spool/cron/crontabs/munin
</code></pre>
<p>After a less-trivial bit of research and learning, it is learned that the crontab entry doesn’t have a “default” context that is specified. Not surprising in hindsight, but not something that you normally think about.</p>
<pre><code># matchpathcon /var/spool/cron/crontabs/munin
/var/spool/cron/crontabs/munin <<none>>
</code></pre>
<p>So what this means is that when you build the munin (or any, really) cron entry, it’ll get the root:object_r:user_cron_spool_t permissions.</p>
<p>The problem is this:</p>
<pre><code># semanage login -l
Login Name SELinux User
__default__ user_u
root root
system_u system_u
</code></pre>
<p>What <em>that</em> means is that the only user on the system that has a designated selinux user (the first entry in the a:b:c context triad) is <strong>root</strong>. Everybody <em>else</em> gets user_u.</p>
<p>So when cron tries to do the transition from whatever cron runs as to the specific context, it fails with the following message:</p>
<pre><code>Oct 22 22:08:39 testbed cron[29465]: (munin) ENTRYPOINT FAILED (crontabs/munin)
</code></pre>
<p>Why? Because the selinux user of “root” isn’t associated with the munin linux user.</p>
<p>To solve this, I set the munin cron file’s selinux user to user_u with the following command, and things ran nice and fat + happy:</p>
<pre><code># chcon -u user_u /var/spool/cron/crontabs/munin
</code></pre>
<p>Result:</p>
<pre><code>Oct 22 22:15:01 testbed cron[29531]: (munin) CMD (/usr/bin/munin-cron)
</code></pre>
<p>I’ve filed <a href="https://bugs.gentoo.org/show_bug.cgi?id=526532">a bug</a> on this due to how <em>fucked</em> this behavior is.</p>
<p>I’m not sure how to properly globally fix this one, or for that matter how this works on other SELinux implementations. But at lease for my part, its’ easy to fix with puppet:</p>
<pre><code> cron { "munin-cron":
command => "/usr/bin/munin-cron",
user => "munin",
hour => "*",
minute => "*/5",
}
# workaround for https://bugs.gentoo.org/show_bug.cgi?id=526532
file { "/var/spool/cron/crontabs/munin":
seluser => "user_u",
require => Cron["munin-cron"],
}
</code></pre>
<h2>4. More fucking munin</h2>
<p>I like to have functionally useful statistics, which include stuff like firewall information. Which is neat when you are fully saturating a link with a tor exit node.</p>
<p>The problem is with a grsecurity-enabled kernel is that /proc is locked down reasonably heavily such that you can’t grab process statistics from other users, so you get undefined or null values when you run affected munin plugins.</p>
<p>Solving this requires you to take advantage of the /proc user. For a Gentoo hardened kernel:</p>
<pre><code>Security Options --> Grsecurity --> Default Special Groups --> "GID exempted from /proc restrictions"
</code></pre>
<p>One you make sure the munin user is a member of that group (defualt of 10, I moved that way the fuck up so I’m not giving munin wheel) you can then view privileged /proc information once again.</p>
<p>Neat.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Perl Fastcgi]]></title>
<link href="http://jowrjowr.github.io/blog/2014/10/23/perl-fastcgi/"/>
<updated>2014-10-23T08:16:42-05:00</updated>
<id>http://jowrjowr.github.io/blog/2014/10/23/perl-fastcgi</id>
<content type="html"><![CDATA[<h3>Perl FastCGI</h3>
<p>If you want to run a script (eg, php or perl) as an application on a webserver you have to actually run the script and do various “things” to manage processes, output, permissions, etc.</p>
<p>The PHP ecosystem has this down pat. Perl, not as much.</p>
<p>When you search for running Perl in FastCGI, you find something like <a href="http://nginxlibrary.com/perl-fastcgi/">this</a> invariably.</p>
<p>The problem is that the scripts do not support running as <em>anything</em> other than <strong>root</strong>. Further, any script STDERR output goes straight into the void so good fucking luck figuring out what’s going on.</p>
<h3>Let’s unfuck this</h3>
<h4>Why?</h4>
<p>A part of one of my projects involves a fair amount of perl as a part of its’ backend that also serves as the frontend administrative interface.</p>
<h4>Oh yeah, <em>fuck PHP</em>.</h4>
<p>Why perl? Because <em>fuck PHP</em>. Why <em>fuck PHP</em>? Read these for an introduction as to the horrors of the PHP ecosystem:</p>
<ol>
<li><p><a href="http://blog.parse.com/2014/08/05/parse-for-php-a-fractal-of-rad-design/">http://blog.parse.com/2014/08/05/parse-for-php-a-fractal-of-rad-design/</a></p></li>
<li><p><a href="http://www.reddit.com/r/lolphp">http://www.reddit.com/r/lolphp</a></p></li>
<li><p><a href="http://blog.codinghorror.com/the-php-singularity/">http://blog.codinghorror.com/the-php-singularity/</a></p></li>
<li><p><a href="https://github.com/search?p=1&q=extension%3Aphp+mysql_query+%24_GET&ref=searchresults&type=Code">oh holy shit</a></p></li>
</ol>
<p>But since PHP is a bit less popular than Perl, the ecosystem is a bit less developed so you have to put in some <em>manual labor</em>.</p>
<h4>RESULT!</h4>
<p>The end result (init script + perl CGI script) is uploaded to github <a href="https://github.com/jowrjowr/personal/tree/master/perl_fastcgi">here</a>.</p>
<ul>
<li>You can run as something <em>other</em> than root.</li>
<li>Actual error trapping and logging to syslog.</li>
<li>Script errors get logged to syslog.</li>
</ul>
<p>This isn’t fully where I want it to be but it is a huge improvement and running in production right now. Much happier with it than before.</p>
]]></content>
</entry>
<entry>
<title type="html"><![CDATA[Time for a New Blog]]></title>
<link href="http://jowrjowr.github.io/blog/2014/10/23/time-for-a-new-blog/"/>
<updated>2014-10-23T05:43:05-05:00</updated>
<id>http://jowrjowr.github.io/blog/2014/10/23/time-for-a-new-blog</id>
<content type="html"><![CDATA[<h3>Who am I?</h3>
<p>I’m Eric, and I decided to start writing about various little projects and efforts I am working on. This has the dual benefits of putting myself out there in a positive light, and to document weirdnesses in various projects that I run that I would like to make public.</p>
<p>I work as an erstwhile Linux syadmin / consultant / developer. My principle focus at this point in time is <a href="http://www.puppetlabs.com">Puppet</a> configuration management, and the special hell that can occasioanlly turn into. Most of my work goes through oDesk, and you can see my oDesk profile <a href="https://www.odesk.com/o/profiles/users/_~01f2546e9a35daff31/">here</a>.</p>
<h3>What am I doing?</h3>
<p>Currently I’m working on a fair number of client projects but the current interest that’ll get the majority of my discussion time is properly teaching myself SELinux via building a fully secure Tor exit node on top of Gentoo, my preferred distribution for anything that deviates from the nice little box that the RHEL family builds for you.</p>
<p>I’m also figuring out how to run Octopress as a blogging platform. Its’ being a pain in the ass but I’m getting the hang of it and I love it far more than the infinitely insecure Wordpress platform, which is such a piece of shit when it comes to security that it boggles the mind.</p>
]]></content>
</entry>
</feed>