LOCUS DEMENTIA

Today I added some add-ons to my splunk and did some sysadmin on the server. Restarted and noted the splunkd was not running. Ahh, well, that's typical. Starting the splunk daemon is easy enough: Start Splunk  - from the people who made splunk. There are two ways to start splunk, as you can read from above. One is to run the "splunk" process from your root shell after logging in. This will run splunk as root. The other is to use the nifty systemctl service script to daemonize the process. Prior to today, I had the same problem and ran the splunk process as root. This was foolish. If you happen to have once started splunk as root, and then successfully started splunk as the "splunk" user, you will find that your splunk login page is empty. You get the background picture, but no input controls. Damn. Google that, nada. Damn again. Today, I learned alot more about selinux and permissions and labels, so I investigated the "web_service" log (/opt/...

If you google "named custom logs selinux" you will find quite a bit of chatter about setting up custom logs outside of /var/log for DNS (named). These posts are interesting, but they tend to be run on posts about learning selinux and becoming an expert on named. What you need to know? If you have setup custom logging locations in your /etc/named.conf file, such as:     channel default_file {         file "/var/log/named/default.log" versions 3 size 5m;         severity dynamic;         print-time yes;     }; Then you will likely see errors like this in /var/log/messages: Oct 26 11:41:13 namedsvr setroubleshoot: SELinux is preventing /usr/sbin/named from write access on the directory /var/named/chroot/var/log/named. For complete SELinux messages. run sealert -l 6eab4aaf-e615-4ade-9e88-4efdc789eaf2 Then you run the sealert command as suggested by the very friendly selinux audit log and yo...

In Microsoft SQL Server you can hash using T-SQL [1] : declare @hash varchar(200) set @hash = '15174141714252' print hashbytes('MD5', @hash) This is a nifty feature, of course, because you can now send your passwords over the unsecured SQL connection and do your hashing on the server. Secure your connection [2] , please, before doing this. Note the use of varchar(200) in the code block. The Microsoft sample shows the use of nVarChar. Does it matter what we use? Turns out, yes. The code block above returns: 0x5B17965D4E33B04FD8848E536165D013 That is also the same hash produced using System.Encoding.GetBytes(blah) and the .NET MD5 digest provider. If you opt to use nVarChar: declare @hash nvarchar(200) set @hash = convert(nvarchar(200), '15174141714252') print hashbytes('MD5', @hash) You will get something different: 0xBA48394E1385A2C633AB7F8339231B56 nVarChar and nChar use Unicode encoding [3] to process the string bytes. The default ...