Caller ID, wiretapping, call recording, and the federal Do Not Call list

There is a witches brew of rules that people making outbound telephone calls need to thread through. Also, the recipient of a call needs to observe some as well. Let's start in reverse order:

Particularly, in the US, some states require consent from only ONE party to a telephone communication; others require TWO [or ALL, in the case of a conference call] participants to so consent. The asserted misconduct case of Linda Tripp in Maryland comes to mind. Linda got into some hot water for chatting up Monica's lovelife with some girltalk about Bill Clinton and recording it without needed consents from "that woman, Ms. Lewinsky" and then turning those recordings over to Kenneth Starr's office

Neither side of the aisle is without stain in this space, it seems; recall that back earlier in the Clinton administration that a couple in Florida recorded a conference call bridge leg, on which the cell phone conversation of Representative John Boehner (R-Ohio), was connected. They later pled out to a criminal charge concerning this. That call (said to have been intercepted within the state of Florida through a common radio scanner) also included then-Speaker of the House Newt Gingrich and other House Republican leadership folks. The tape turned up, inter alia, into the possession of Representative James McDermott (D-Wash.), who then flipped the tape to The New York Times and the Atlanta Journal-Constitution. This drew a lawsuit from Boehner against McDermott, seeking to impose to civil liability for violation of the federal [anti-]wiretap law, alleging that no effective consent existed

Stock brokers commonly record ALL calls, and I assume have paperwork in place at account opening time, that effectively and irrevocably obtain consent to such monitoring and recordation, and as I think it through, must contain some sort of representation and warranty by the customer that all parties connected from their side of the call brought in have also consented. Clearly, sometimes this turns out NOT to be the case, and yet I do not recall seeing any litigation as to improper recording of a conference bridge. Curious

And then there is the federal Do Not Call list -- seemingly a shield for the consumer to ward off unwanted solicitation calls from unknown third parties. All the phone numbers under my control have been registered with the enforcing agency, the FTC, and should be showing up on the database tapes for telephone solicitors to elide. This does not happen of course -- sadly, anonymous VOIP calls, false and forged Caller ID information, and simple omission of caller ID data prevails; the ways to dodge the requirement are well know to telemarketers, it seems

But I have been working in the caller ID adjunct industry -- if you need real time screen pop information of inbound callers, I have been a rep for TelComp -- for longer than I care to remember. Be sure to mention that Russ sent you if you call Larry directly, or contact me for a system design and suggested implementation

I was on the phone with Larry earlier today. We have provided the web and email presence since the start. The domain registration says 1995, but I know we did a trade show in LA before that with a web presence up. I was doing a bit of debugging on SMTP AUTH issues with him. Commonly we will leave an open line when we do this, and I listened to him field calls for an hour or so. Larry is endlessly patient on support calls, and I hope to be as patient when I am doing support. ;)

The call had discussed industry trends and practices, and in part the topics of this blog post were fresh in my mind, for we 'talked shop' during running down his email issue

The next call, not two minutes later, went like this:

Phone rings, and the caller ID has no name information, is from a number not known in a lookup to my real time 'whitelist' database, and is from out of the local area code --- a potential outbound solicitation call

Me: Good afternoon. May I help you?

Other party identifies himself as calling from "Merchant Services" and asks for 'the decision maker' at my business.

Me: That's me, all right; we have a practice and policy of recording all calls for quality and training purposes. May I have your consent to such recording, please?

Other party: (confused) uhh -- OK, I guess

Me: Great, and thank you. How may I help you?

Other party: Well, I am calling about your merchant services account. I was calling to make sure you were getting the best rate ...

Me: (interrupting) Sure -- thanks. What is your firm's name and address please?

Other party: ummm

Me: (interrupting) ... you see, I need that because this is a residential number that is on the Do Not Call list, and I need that information to send the lawsuit papers to ...

Other party: (click)

Much more satisfying that simply silently hanging up at my end. Feel free to "clip and save" this handy outline. A copy to crib from at each phone just may come in handy

CentOS 4 series on K6-II

Tru just pointed out http://i586.centos.org/ which is an archive of the fruit of the push to get the AMD K6-II / Intel i586 install ISO working.

Nice stuff, and nice to know the effort was not wasted...

... I am the eggman

One recent addition to Python modules packaging at Red Hat in its Fedora project, is carrying along an additional, and optional structured metadata about the contents of that module (package), held outside of the RPM database

This additional information: egg-info came into Python at Python version 2.3 and following. More may be learned about these eggs at: egg-info (optional extra Python metadata about a Python module).
See: Fedora specifics

This new detail is a two edged sword. On one hand, it provides sufficient information that an ad hoc root level process, for when one using native Python tools that it makes for an easy_install [the skeptic in me suggests it might be 'easier', perhaps, along some skewed axis of metric of goodness]. See also the egg superset, Python setuptools which now work well in RPM-mediated space

Sadly, down this path, modules which are outside of the protections and managae-ability of the RPM packaging system may "easily" and inadvertently be introduced by an incautious admin, and thus introduce of Python code into a otherwise controlled system. This is the horror of a mixed RPM and CPAN system, all over again. As I say, one needs to choose a 'metric of goodness' with care

Incautious use of mixed packaging approaches in turn can lead to possible security and updates headaches. Using such non-packaging system tools can break the SPOT -- single point of truth -- to determine to what versions of binaries a given host is using. From sad experience, this way lies additional work, and madness

But on the other edge of that blade, the egg-info adds descriptive narrative, and cautiously used, increases the usability of a system that does not (ab)use those native installation tools

As noted, the FOSS world has faced this problem before with perl and CPAN. Weak and strong 'includes' versioning and security model questionable @INC 'include' path search practices in Python and perl are well known failings in their community archive models. I faced it recently in a packing push of CRAN modules for R -- hmmm, I still need to file a few bugs upstream to solve some problems I saw in some R module packaging choices that I consider poor ones

There is not a single, objectively 'technically right' way to proceed, but rather just one consistent, or not consistent with packaging system design and usage choices

Fedora helpfully offers a sample stanza to use in .spec files. I cruised my archive of .spec files to see what else turned up


# See if there's any egg-info
if [ -f %{buildroot}%{python_sitearch}/Conch*.egg-info ]; then
echo %{buildroot}%{python_sitearch}/Conch*.egg-info |
sed -e "s|^%{buildroot}||"
fi > egg-info


and later then using the %files stanza's -f file list option


%files -f egg-info
%defattr(-,root,root,-)
%doc LICENSE NEWS README doc/*
%{_bindir}/cftp
...


It appears I need to do some work in my local archive of SRPMs. Never enough hours in the day

Like a stake through the heart

The CentOS 4 series point refresh has been released to the mirrors for a couple weeks now, and the updates it backlogged as well. But the AMD K6-II / Intel i586 install ISO was not right when we shipped, and we knew it

Akemi 'toracat' Yagi had it working in her side archive, and kept working the issue with Johnny 'hughesjr' Hughes, and candidate ISOs have been in testing in the QA back channel. I get a 'heads up' on a new testing from hughesjr yesterday afternoon, and around 5 am today, a notice that a new candidate was ready for pulling and testing

I put lftp to work, and burned the CD. Booted with the command line parameter:

: i586 text

and did a minimal install

Eureka -- it works in mainline CentOS

Coming soon to a mirror near you (for the four or five users of such old kit). The unit I am testing on was my workstation on 11 September 2001, and I long since consigned it to the boneyard

---

090902: fixed grammatical error

A bit more on CentOS 4.8 and the K6-II

Yesterday's post on the K6 covered getting a CentOS 4.8 beta candidate installed on ancient hardware; The careful reader may have noticed that I had an unexplained list item early on in that outline:

Add to /etc/yum.conf

exclude=kernel*

This is not something that just occurred to me unbidden, but rather came from an awareness that the upstream has had the dreaded 'Regression' from time to time in its RHEL 4 series, where a patch needed to support the K6/i586 architecture was not consistently present. In reading the bug comment notes, it seems that the 'boneyard' available to the member of the kernel testing team tasked with this is not so full of carcasses as mine, and so he cannot test his fixes as well

So, I took affirmative steps to preemptively 'partition away' the need for an updated working kernel from our 4.8 beta install candidate, and yet be able to get to a working chassis with the kernel from the 4.5 final image, which is known to work. Good thing. The regression is back in the 4.8 kernel SRPMs, and the needed patch got dropped, it seems (this from an initial workup -- detail testing will be needed to see)

---

The workaround is straightforward; Akemi 'toracat' Yagi maintains a testing 'plus' archive, containing kernels with the needed patch, and I can confirm that her candidate works fine. see: http://centos.toracat.org/kernel/centos4/centosplus-testing/i386/

Thanks, toracat

Advancement of technical skills with CentOS project tools

I posted this piece inside a post on a runaway mailing list thread on the CentOS mailing list. It represents my opinions, and are not some policy statement of the CentOS project. To a degree it reprised earlier pieces on how to advance one's technical skills with CentOS, but it is worthwhile carving it out, so I have a reference point to discuss sub-pieces of, here. Others have other views

---

If a person wishes to be advanced in the CentOS project, contribute to the project. [It is not clear to me WHY people think there is some huge benefit for being a 'project insider' as it is really just a chance to do more work. Early access to QA is just not that hard to earn] We are not likely to hold your hand much, but will answer questions well framed. Be a self starter. Do something material. Some things to do to gain my notice as a contributor of merit:

1. The bug tracker is open self serve for people to sign up. Add its RSS feed, and read every one as it crosses. Start working through the bugs to replicate or note an inability to replicate issues; Work through the bug tracker from latest to earliest, seeing if there is a similar upstream bug, or a fix, or if an issue is CentOS local. Note your results. That would be useful
2. The centos-docs ML is open for proposals of new content into the wiki. Add its RSS feed, and read every commit diff as it crosses. Fix broken stuff that can be fixed at once. Some even believe it is more useful to re-write documentation locally rather than feeding improvements upstream so that it flows back down and out into RHEL, Fedora, etc as well as just CentOS [I do not, and refer you to Fedora to push non-centOS specific content out more widerly]
3. Set up a local mirror of SRPMs, not just of the released Enterprise sources of upstream, but its RawHide as well. I have a daily diff report in my email queue each morning to scan for new material to review. Start building and testing and filing bugs to make the .spec files more general and less distribution specific, so that cross pollination can occur. You may get rejected (I often am), but at least try to improve the breed
4. The same problems repeat time and again in the Forums. Add its RSS feed, and read every new post as it crosses. Add pointers or content as needed, and 'cc' into updates on the thread. I have noticed a excellent trend, that lately the three or four regulars are moving content more to the correct tree location, and asking questioners to do their research, and dropping out-links to answers rather than doing so in line. I like to do this as well when I form an answer, there on on a mailing list that is archived, as it provides the linkage hints Google needs to note 'reputation' and to weave answers together
5. Join the main IRC channel or mailing list, and confirm you can answer every question posed for a solid week; if not, fill in your knowledge gaps with experimentation. At that point, start thoughtfully pointing a person toward the answers. Spoon-feeding is NOT a good thing, and does not gain any points in my eyes, as that is not the stated purpose of the channel
   
   The mailing list is looser as to /on topic/ but when a person repeatedly recommends 'non-CentOS' approaches over acceptable CentOS product, I'll certainly notice ... and that is perhaps not a good thing for further advancement. I _USE_ tinydns some places where it is the right fit, but I don't mention it here
6. Once you have demonstrated skills, ask to be admitted to the next QA effort (we get three of four point update chances a year), and do QA. People who sign up and are admitted often slack off [don't participate in the ML, don't file reports, are not in IRC], and by that inaction demonstrate they are are not interested in progressing further. People _do_ get busy with real life or have to rest from burnout and take time off
7. Once you have demonstrated skills, ask for some special project to build some element of needed infrastructure that is not otherwise getting done, and do it. John Pierce's post earlier this week certainly caught my eye, as he demonstrated self-starter problem solving skills in a complex space I had not seen before. He is now on my 'watch list' to draw into the project

---

More personal opinion: Will any of those 'earn' a centos.org mailing address as someone lamented they lacked earlier in this thread? Sometimes, but frankly, we don't give those out easily. I saw a remark earlier:

In the meanwhile some things ... are getting a bit clearer so I guess we are on the right track

'We' can perhaps be read here as a generic 'things are on the right track' -- but frankly, the only 'we' that I would look to for authoritative statements as to the project are people with a '@centos.org' in their email address. There is back channel coordination, infrastructure, and much more

Beta testing CentOS 4.8 with an AMD K6-II

Painful does not begin to describe how laborious it seems, after using more modern kit.

It appears that the AMD K6-II instruction set is a superset of that used on the i586 series. Some folks seem to be still running such, and we have a number of resolved bugs in the tracker, detailing various ways to get the units running

Based upon exhortation and advice in the CentOS QA mailing list and some IRC banter, I was induced to drag one of these poor exhausted clunkers out of my boneyard, and do some testing on it

These installation instructions SHOULD work on i586 as well, but I no longer have an examplar to confirm with:

1. Download and install using 4.5 i386 ISO from vault.centos.org and start it up the following options
   
   Boot it with: i586 text nomce
   
   
2. Manually install openssh-server, enable, and set up with iptables, so you can hop on the unit from a remote box to work on it
3. Add to /etc/yum.conf
   
   

   exclude=kernel*

4. Perform a general run updates against the intervening changes prior to 4.8 -- (seemingly 4.7 and intervening updates when I perform this testing) -- lots there, but get it close to current.
   
   

   Install 6 Package(s)
   Update 150 Package(s)
   Remove 0 Package(s)
   

   
   ... took forever as I only have 128k ram for this old beast --- 308 transaction steps
5. Do an interim reboot
6. Point at my local mirror of the CentOS 4.8 release test candidate and let it rip --
   
   
   

   first pass only:
   ftp://ftp.first.lan/pub/mirror/centos/centos-qa/CentOS/4.8/os/i386/
   
   without the later pending updates:
   ftp://ftp.first.lan/pub/mirror/centos/centos-qa/CentOS/4.8/updates/i386/

   
   
   

   Install 1 Package(s)
   Update 83 Package(s)
   Remove 0 Package(s)
   Total download size: 117 M
   

7. Do a second interim reboot
   
   Mysteriously, I got an 'unclean shutdown' FSCK required message as to /boot here ... no idea why
8. Run yum again, for a second pass with the updates
   
   

   Install 0 Package(s)
   Update 9 Package(s)
   Remove 0 Package(s)
   Total download size: 9.8 M
   



9. Do a final interim reboot
10. I completed by my test suite without incident

I am advised similar steps may work from later than a CentOS 4.5 ISO, and that i586 should work as well. As I lack the hardware to test this, your mileage may vary

Poor old boxes. Let them rest. Save power. I need a shower. Yuck