Open Records Ps & Qs

Uncategorized

Ohio sunshine laws give a pretty generous berth to those requesting records, but as with anything there are limits. This has come light in the small community in which I live where a local resident has determined to take his personal issues out on anyone and everyone, including the local (and even not-so-local) government officials. In his rampage he has managed to run afoul of all three no-nos I’m aware of in regards to Ohio public records law so it’s as good a time as any to list those for anyone who might want to know:

  1. You can only request a document once. Although not warned via email, the resident would make a request for some specific documents, and then later request a range in which the previous documents were included. Not as bad as the other offences, but it fits a pattern of behavior.
  2. You cannot request a document that doesn’t exist. This seems obvious, but the requester in this case made repeated requests for a ‘draft’ document that did not exist, and, not satisfied with not getting that document that did not exist, he then demanded that I create documents on various informal procedures that I follow. The requestor was warned repeatedly about harassing me for documents that don’t exist, which of course resulted in just more harassment.
  3. No fishing expeditions. This was actually the last straw in that the requestor made a request for a wide range of records (six years of complete payment records) and when that was denied he started cutting up the request so that he could get all six years in six different requests to circumvent the rule.

He also later stepped in a fourth no-no when Ohio said that Fiscal Officers (and others I believe) no longer had to stack up all their post-it notes for possible records requests. He, of course, continues to this day to request such “records” despite my repeatedly telling him that he is not entitled to them (with one trustee wondering what the point of his request was anyway since my handwriting is, alas, pretty illegible).

His attempts to game and abuse the system is part of what led to our record requests being filtered by our lawyer. To what end he’s leveling this abuse I do not know since from all his conversations he’s only read the contents of maybe one request, one that he has repeatedly lied about the contents of. I would think that if he was just going to make up the substance of a document why did he bother requesting it to begin with? He could just say that he got whatever documents he imagines, real or not, and then he’s free to make believe they say whatever he wants. It would be freeing in a way, for everyone. Who knows, he could even imagine that in one of our documents his dad still loves him (or whatever his hang-up is), giving him some modicum of peace.

Anyway, I’ve spilled too much ink on this guy already, my brain feels dirty even thinking about him so here’s a picture of our sheep from back in the winter:

Bluescreen 0xc00002e2

Server Support

Judge a smidge of background first. I came in this morning and the Hyper-V guest of our windows server domain controller was getting paused while booting with a disk IO error of some sort inside the VM (there were no error within the cluster itself). It turned out that due to an issue I’m having with the DPM backups that I had a half dozen snapshots stacked up for the server. After merging them all the server then stopped getting paused but then did bluescreen with the error 0xc00002e2 and the Internet was less than helpful.

The error is caused by an issue with the active directory database and running a repair on it helpfully fixed it up. I first booted to the repair mode command prompt and tried to run esentutl /p against ntds.dit, but it failed with the error “Unable to find the callback library ntdsai.dll” and the fix for that was to run the utility from the Windows instance that was being repaired. In this case the repair tool dropped me off to an X:\ drive, but the Windows instance that I wanted to repair was actually the E: drive. So I changed the path to e:\windows\system32 so the command was something like:

cd e:\windows\system32
esentutl /p e:\windows\ntds\ntds.dit

I honestly figured it would fail, but it ran through successfully and the server booted up fine afterwards. Note that I have other DCs for this domain so I didn’t have to worry too-too much about the actual data and state of the DS database since it was just going to plowed over with the objects from one of the other DCs.

Data Loads in CSI/Syteline

ERP

Nothing too extraordinary here, lots of “paste rows append” in the grid view, but I’ll touch on a few notes from our experience.

Our first sets of data loaded were the customer and vendor tables. These were sometimes loaded months before go-live to get the different groups used to going into the system to keep the records up to date. That might not be workable if these records change frequently, but even a week ahead of time should be reasonable.

The issue with Customers in particular is that there is no good way to load the ship-tos in an easy, automatic fashion since the ship-to ranking can only be set after the record is loaded. Our workaround for that was to set the records manually, and that’s something most places will only want to do once. Another issue for both customers and vendors is that there is a lot of tuning to the records during testing and it would be difficult to handle that in a coded export.

The setup for Customers has a generous number of areas where addresses and contacts can be added, but for vendors there is just the one record, plus a second record, of sorts, for the remit-to (only one remit-to can be set). This is an intractable issue with the package since expanding Vendors to work similar to customers would require quite the set of database changes. The only thing I will note here is that for both Customers and Vendors we used a truncated version of the customer’s/vendor’s name instead of auto-numbering (CSI doesn’t do a good job of enabling users to easily find names) and we prepended the vendor’s remit-to with ‘ZZ’ to help in more easily differentiating them from the main address.

Items is the a database table that was usually loaded a couple days ahead of time. Note, this burned me every time since production did a poor job of keeping the records up to date, even over the course of 72 hours. I tried to control for this by having my router export program tell me which parts did not have a match in CSI (the router was exported out of the old system, but it couldn’t find a corresponding part in CSI). Even at our smaller operations it took several hours to paste the Current Operations into the system, but a big tip: refresh after each data segment is pasted in. So for instance, I would generally paste 1,000 rows at a time, and after the paste completed and I saved the records (without an error hopefully!) I would refresh the form so that only 200 records were on the form. If the form is not refreshed CSI gets slower and slower as it has to keep track of progressively more and more data.

The last thing I want to touch on is importing WIP value, and importing shop floor transactions: both of these had to be done by hand. Obviously the goal is to “run out” as many jobs as possible to minimize this work, or at the very least, complete/close operations in the legacy system. For the WIP value we issued a fake part to each job that had the current WIP dollar totals for the job (when asked to create the part, just click Cancel). For the shop floor transactions it was as much fun as it seemed: as many people as could be convinced to come in over the weekend would be trained to both key data into Unposted Job Transactions and close out operations on Job Operations. If possible, this process can be helped greatly by having someone from production helping so as to catch last minute operator keying errors.

Redundant Fortigate VPN with Cradlepoint

Network Communications, ,

This post is working from the following assumptions:

  • The Cradlepoint devices are using Cradlepoint’s cloud management service. Otherwise the routing between the Cradlepoint and the protected network needs to be set up. I was unable to get this to work, though I didn’t put any time in to it since I didn’t have to get it to work.
  • A pseudo “Spoke-Hub” setup, with the redundancy of the hub to the spoke not being of great concern. In this case our hub site is a cloud provider that uses Fortinet’s hosted version of a Fortigate.
  • I am not an expert in this field, some of these steps may not be needed or the configuration suboptimal in some ways. I am just relating what worked for me.

The initial setup of the spoke site is a simple site-to-site VPN utilizing static IP addresses at each site:

That link will need to be redone since the new connection at the spoke site will need to be an aggregate VPN and the existing IPsec tunnel cannot be set as an aggregate member. I recommend using the USB configuration load so that if the process goes south, the Fortigate can be rebooted and the old, working configuration reloaded.

First, the Cradlepoint needs to be set to a dedicated interface on the Fortigate. For most of the sites I used Wan2, though at one I had to take a port out of the Lan configuration. Optimally this port will be part of a separate network so that a system can be hooked to other ports in the set for diagnosing subnet specific issues, but, I forget to do that every time. With that set, I set two equally weighted static routes to the static IP address of the Hub, one through the existing gateway, and one through the internal address of the Cradlepoint. (I did this because the only thing I wanted routed over the Cradlepoint was work traffic.)

Next, make a new VPN connection at the Hub that will listen for the Spoke connection. This will be a “dial up” VPN connection; I used IKE2 and Forced NAT transversal based on recommendations from Fortinet’s support forum:

The at the spoke site I then setup a matching VPN connection, being careful to mark as an aggregate member:

Next, setup a new Redundant IPsec aggregate on the Spoke and add the new VPN connection to it. On the Hub site add a new, equally weighted, static route to the Spoke’s network using the new VPN connection made at the hub and add policy rules allowing traffic over it.

So far this has been non-destructive, but the next step will interrupt the connection for a bit, depending on how fast you are. On the spoke, change the default gateway to the hub network from the existing VPN connection to the IPsec aggregate, and then change the policy rules used to allow traffic to (and from) the hub to use the IPsec aggregate as well. At this point, the VPN connection over the Cradlepoint network should come up, if not diagnose and fix the issue (every time I had an issue here it was because my settings in the VPN connections did not match up).

Next, delete the old VPN connection on the Spoke system that went to the Hub network and recreate it, this time as an aggregate connection.

In this next step I usually add the new, re-done, VPN connection to the aggregate and then remove the Cradlepoint aggregate to more throughly test the connection. Once I confirm that it works I add the Cradlepoint back into the aggregate. I then test the redundancy by “breaking” the regular VPN connection at the hub (by changing the passcode, etc.) and the Fortigate should fail-over to the Cradlepoint VPN. When I “un-break” it, it should fail-back (confirm by resetting the statistics on the VPN monitor).