|Friday 24th February 2012|
|13:00||Corman's World: Exploits of a Hollywood Rebel|
|16:00||Tape 407: The Mesa Reserve Incident (aka Area 407)|
|23:00||War of the Dead|
|Saturday 25th February 2012|
|15:30||Rites of Spring|
|18:30||L’Arrivo Di Wang / Wang’s Arrival|
|Friday 22 February 2013|
|13:00||The American Scream||IMDB|
|15:00||Sawney: The Flesh of Man||IMDB|
|17:30||The Lords of Salem||IMDB|
|23:00||Detention of the Dead||IMDB|
|Saturday 23 February 2013|
|13:30||Bring Me The Head Of Machine Gun Woman||IMDB|
|18:30||ABCs of Death||IMDB|
It took me a while to figure out why posix_getgid, posix_getegid, posix_getuid and posix_geteuid weren't working on my CentOS 7 installation of PHP. In fact none of the POSIX commands were available. PHPInfo revealed nothing, it didn't even mention POSIX. On checking the PHP web site it said that all the posix_* commands were built in and needed no configuration to switch them on!
I did a bit of hunting around and I found that RHEL and CentOS distributions of Linux compiled their version of PHP without this module, sighting that it was a security hole to allowed these commands to be run.
If you really want it for development servers, then you can easily install it via the yum process:
yum install php-process
but you must restart httpd after installing it:
systemctl stop httpd systemctl start httpd
A huge company might have a support email address of email@example.com. Emails that are sent to this email address are not received by a single person and then forwarded to an account manager, they typically go into a customer management system. Their subject, reply identifier and who it is from are matched with on going emails hidden behind support tickets and the whole thing is tied together in a way that allows customer service executives to analyse how well they are dealing with their customers.
These systems cost a lot of money, require people to run and generally don't make sense to have unless you have more than one person doing the same job role. If you have a small company where there is one salesman, one accountant, a couple of techies and a managing director then a standard issue tracking system will suffice. In this kind of company everybody knows their customers and can enter information into a tracker, and if Bob isn't in today then he'll get to them tomorrow because he is the only person who knows how to handle that particular enquiry.
But what happens when Bob leaves, goes on paternity leave or has a serious accident. When you work for a company with the customer management system this is not an issue because those emails were never sent to Bob, they were sent to a pool of people logged into a management system. All Bob's business relations have been sending their enquiries to firstname.lastname@example.org so how do we tell Bob's contacts that they must start using a different email address. Here in lies the problem.
What most small companies do is they change Bob's password and various other people log into his email account and essentially pretend to be him. This is open to all kinds of problems. Bob might use his work email for his personal banking for example. You as a company are opening Bob up for an unscrupulous employee to steal his identity. There is always the question of who owns the email account and the email in it. The users think they own it when in fact the company owns it. This can also be a bone of contention when Bob returns from his operation only to find out that is colleagues have been through his personal mail while he was away and know about the nature of his sensitive operation or his ongoing affair with the secretary.
Another side effect of trying to reuse Bob's account after he leaves is that there is no handover. Bob's account is left open and if you pay per email address (like with Google) then this is costing you money. The excuse of we need Bob's email history is a poor one as services exist to transfer email from one account to another. [ Small plug for me, use my contact form to ask about our email transfer services. ] Generally what happens is that the company is now paying for a lot of email addresses from people that have left because they are too frightened of missing something instead of creating a procedure to handle a person leaving.
What I generally advise my customers to do is think about the roles that your company does that lead you to interact with the outside world. For example your internet account, web hosting account and domain names, all your social media accounts might be the responsibility of Bob. While your HMRC VAT account, accountant, auditor, companies house might be the the responsibility of Sarah. You may have to hire seasonal staff to do maintenance services in summer because more people come through the gate as a result there is more damage or vandalism. It might not be the same person each year but they would still need to be registered with trade suppliers and the like. In the winter there is not enough work for a whole extra person and Bob would handle it.
If Sarah or Bob leave it can be a real nightmare changing all those email addresses you have registered with Twitter or the Revenue. Forms usually have to be filled in, signatures and declarations have to be made by post, the whole process can take a long time and is subject to all kinds of delays. To use our example if Bob signs up for a new internet social media network or a new cloud sharing system site he will use the email alias assigned for that role e.g. "email@example.com", but if he signs up for a tools manufacturer's monthly newsletter he'll use "firstname.lastname@example.org". If Sarah has to sign up for corporation tax online she might use the email address "email@example.com". Your companies internal IT person would create an alias for "it" and "accounts" and make them point to Bob and Sarah respectively. The alias "maintenance" would be assigned to Bob in the winter and then re-assigned to whom ever they hired during the summer months.
Now it is simple for the company to continue its services with external organisations when Bob is replaced with Jeff. The internal IT person will simply redirect firstname.lastname@example.org to email@example.com. The external companies don't need to know or care that you have made a staff change.
The granularity of this is worth spending time thinking about though. Sure you can have one email for every service you sign up for but there is an administrative overhead for all of this. Part of that overhead lies with your IT department but mostly it becomes about managing all those accounts on different systems and their related different passwords. Generally speaking think in terms of roles and responsibilities and you won't go far wrong.
I had a development server that was taking ages to start. I checked the
/var/log/messages file which didn't reveal anything so I checked the
/var/log/maillog which showed the following lines:
Nov 11 16:16:11 myhost sendmail: My unqualified host name (myhost) unknown; sleeping for retry Nov 11 16:17:11 myhost sendmail: unable to qualify my own domain name (myhost) -- using short name Nov 11 16:17:11 myhost sendmail: starting daemon (8.14.4): SMTP+queueing@01:00:00 Nov 11 16:17:11 myhost sm-msp-queue: My unqualified host name (myhost) unknown; sleeping for retry Nov 11 16:18:11 myhost sm-msp-queue: unable to qualify my own domain name (myhost) -- using short name Nov 11 16:18:11 myhost sm-msp-queue: starting daemon (8.14.4): queueing@01:00:00
The salient line for the delay is:
My unqualified host name (myhost) unknown; sleeping for retry
myhost was in the
/etc/hosts file and it resolved just fine. I typed
domainname and got
(none). It's a development machine so I didn't want to set up a domain for it.
The solution was to alter my
/etc/hosts file to include the localdomain suffix thus:
192.168.0.200 myhost myhost.localdomain
Now sendmail starts quickly as expected.