OldTroll's questions

I'm sort of learning the edges of SELinux and I'm wondering if it's possible to prevent a specific user from accessing /tmp.

Clearly it's a bad idea to dork all permissions, so I'm hoping that SELinux can maybe target or restrict a little more precisely than just banning all users.

Additional Information

There is a process that has it's own internal temp space, but under "other" circumstances will try to write to /tmp. I'd rather the process explode and die horribly than actually dump to /tmp since it causes all manner of other problems. -- yeah, clear as mud, right?

For clarification, the data written isn't confidential, but also has no place on the server. If it were possible I'd just dump it to /dev/null but that seems less than reasonable.

References

http://hg.openjdk.java.net/jdk7/jdk7/hotspot/file/97b64f73103b/src/os/linux/vm/os_linux.cpp (about line 1624) (source inspiration https://stackoverflow.com/questions/1924136/environment-variable-to-control-java-io-tmpdir)

I have a trio of CentOS 6.4 machines that I'm trying to configure to use iSCSI. Basically two different initiators talking to two different targets on a single host server.

On one machine, "the server", I have two targets defined in /etc/tgt/targets.conf each target points to a different logical disk. The configuration stanzas are nearly identical, varying only in their names and initiator-address fields.

These are the lines from /etc/tgt/targets.conf that aren't commented out.

default-driver iscsi

<target iqn.2013-08.com.example.group:backup>
  backing-store /dev/primary/backup
  initiator-address <ip address>
  incominguser username password
</target>

<target iqn.2013-08.com.example.group:migrations>
  backing-store /dev/primary/migrations
  initiator-address <ip address>
  incominguser username password
</target>

When I run tgt-admin -s I show two targets as expected. However, one of the targets shows only 1 LUN (0 Controller) while the other target shows 2 LUNs (a Controller and a Disk). I have no idea if this is significant.

Sadly, the first target (w/o a disk LUN) is able to be reached by it's initiator and the machine can mount the space and it's all peaches and cream. The second target (w/ the disk LUN) can't be reached by the initiator. When I run iscsiadm -m discovery -t sendtargets -p <ipaddr> I get back iscsiadm: No portals found.

What's worse, even if I when the second target to expect connection from the other address, or remove the initiator-address portion of the configuration, no other systems seem to see the second target.

First, please excuse my ignorance on this topic. Until recently I had been blissfully ignorant of this field and only recently began to suspect that I'd need to become directly involved. In any case I find myself feeling about and trying to get a survey of potential issues. This the first in what may well be many questions, let's hope I don't screw up too badly.

At work I've been told that we have three ESXi 4.x systems in a cluster. As a result of being the certified hardware tech in addition to other duties I was checking these servers warranty status and associated information. I noted that the three servers have only 2 physical NICs each. So then it dawns on me that the primary admin has been complaining about these three machines and not being able to do some specific network configuration that he has in mind.

So I start getting a little itch that something isn't right. In a past life I know we had a quartet of clustered servers that had 6 physical NICs each so that they had redundant paths to their private cluster only network, their iSCSI interface to the storage array and then redundant paths to the 'real' network.

All of which leaves me with the following questions:

1. Does that logic apply to an ESXi cluster?
2. Do they need a private network for health and system state communications?
3. Shouldn't there be a 'shared' disk or volume for the cluster to be able to fail over? If my understanding of the configuration is correct, each member of the cluster has images for the systems they're running, which doesn't seem right. I can't imagine how ESXi would be fault tolerant if the disk array spins down on a member.
4. Would a vSwitch figure in here and how? One of the complaints from the other administrator is that he's not certain that the cluster can span switches or share network space (i.e. a VM on Host A is able to reach a VM on Host B via a shared internal network).
5. Given the nature of my questions, is there a recommendation for some form of deep-dive immersion to get up to speed? Training? Books? Website? Hypnotherapy? Or should I just drink the Kool-Aid?

I'm not certain that this shouldn't be configured as a community wiki as several of the questions 'feel' opinion based. Here to hoping there is a single opinion for at least some of the questions.

Thanks for the help and any amount of clue is appreciated.

Can anyone verify that there are performance reasons to exclude the "generic" comments from either httpd.conf or php.ini? Personally I find the admonitions and associated clutter to be more distracting than anything else, but I can't imagine that it creates a much of a performance issue since I don't think they are read except at start-up. I'd like to standardizing on just including real configuration comments and scrapping the cruft and can't think of any reason why it shouldn't be fine.

I installed PHP 5.2.11 and upon enabling the php_mssql.dll module (and the obligatory restart of the services) started receiving warnings about not being able to load the dynamic library. The operating environment is IIS ISAPI under Windows 2003 R2. Here is the list of things that were checked

1. File Exists in \PHP\ext directory and has the same timestamp as the other distribution delivered libraries.
2. Permissions are correct to the file. Other extensions are enabled and functioning with identical permissions.
3. ntwdblib.dll has been copied from a SQL Server 2005 installation (per php.net's requirements for the module)

Other modules before and after the php_mssql entry are working. I've also stripped down and remove all non-essential references with detectable improvements. I turned up logging and enabled all the error logs in the php.ini, nothing is generated by the logs.

Searching Google has turned up a slew of closed/unsolved bug reports on php.net and some miscellaneous near-matches, none of which have really addressed the problem or lead to any inspirations.