More netsh firewall command options in Windows.

Here is some very good information from Microsoft for the netsh command in Windows:

http://support.microsoft.com/kb/947709

I have just listed a few of the commands in both the new version of the command and the old.

Show all the current firewall rules:
New:

netsh advfirewall firewall show rule name=all

To disable or enable all firewall profiles (Domain,Private or Public):
Old:

netsh firewall set opmode ENABLE

Old:

netsh firewall set opmode DISABLE

New:

netsh advfirewall set allprofiles state on

New:

netsh advfirewall set allprofiles state off

To reset the firewall back to the defaults:
Old:

netsh firewall reset

New:

netsh advfirewall reset

To log firewall activity:
Old:

netsh firewall set logging “C:\FWLogs\FW.log” 4096 ENABLE ENABLE

New:

netsh advfirewall set currentprofile logging filename “C:\FWLogs\FW.log”

To open or close access to a network port:
Old:

netsh firewall add portopening TCP 80 “Open Port 80″

Old:

netsh firewall delete portopening TCP 80 “Open Port 80″

New:

netsh advfirewall firewall add rule name=”Open Port 80″ dir=in action=allow protocol=TCP localport=80

New:

netsh advfirewall firewall delete rule name=”Open Port 80″ protocol=tcp localport=80

To enable a program:
Old:

netsh firewall add allowedprogram C:\myprograms\myprogram.exe “Allow My Program” ENABLE

New:

netsh advfirewall firewall add rule name=”Allow My Program” dir=in action=allow program=”C:\myprograms\myprogram.exe”

Chroot SFTP only on CentOS 6.

CentOS: 6.6

When setting an SFTP server, you may want to restrict or jail the SFTP users to only one location without restricting all aspects of openssh. This is how I restricted SFTP without impacting all of openssh:

Create the group you will match to and therefore add users to to grant SFTP access:

# groupadd sftp

Create a user:

# useradd -G sftp -d /into -s /sbin/nologin testuser

Notice the home directory. This is the logical root location for the user. Also, note that the shell is nologin to prevent ssh access.

Set the password:

# passwd testuser

Make a backup copy of the sshd_config file and make the following changes to the existing file:

# cp -rp sshd_config sshd_config.orig
# vi sshd_config

# JGZ – Force to use openssh in-process sftp server
#Subsystem sftp /usr/libexec/openssh/sftp-server
Subsystem sftp internal-sftp

# JGZ – Match to group to chroot
Match Group sftp
ChrootDirectory /sftpdir/%u
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp

Restart the service:

# service sshd restart

It is very important that the directory permissions are correct. Create directories and set permissions:

# mkdir /sftpdir
# chmod 755 /sftpdir
# ls -ld /sftpdir
drwxr-xr-x. 3 root root 4096 Feb 27 05:53 /sftpdir
# mkdir /sftpdir/testuser
# chmod 755 /sftpdir/testuser
# ls -ld /sftpdir/testuser/
drwxr-xr-x. 3 root root 4096 Feb 27 14:57 /sftpdir/testuser/
# mkdir /sftpdir/testuser/into
# chown testuser.sftp /sftpdir/testuser/into
# chmod 755 /sftpdir/testuser/into
# ls -ld /sftpdir/testuser/into
drwxr-xr-x. 2 testuser sftp 4096 Feb 27 15:07 /sftpdir/testuser/into/

It should be simple enough to create a script to create new users. Basically, this what you need:
# useradd -G sftp -d /intocbb -s /sbin/nologin testuser1
# mkdir -p /home/testuser1/intocbb
# chown testuser1.sftp intocbb/
# passwd testuser1

Nagios log date conversion

To convert the nagios date timestamp in the nagios.log to a standard time format, use:

perl -pe ‘s/(\d+)/localtime($1)/e’ /var/log/nagios3/nagios.log

Linux “at” command

Long ago I used to use the at command quite often in a Unix environment. I would just use the following syntax:

# at now /path/scriptname

And it worked.

Now, in Ubuntu, when I use the same syntax, I get the following:

syntax error. Last token seen: /
Garbled time

The solution is to enter “at now” and hit enter. At the at> prompt, enter the full path and name of the script you want to run. Then, hit Ctrl-D to run the job and exit out of at.

# at now
warning: commands will be executed using /bin/sh
at> /path/scriptname
at>
job 7 at Thu Oct 30 11:30:00 2014

Inactive VMware ESXi NFS volumes.

Sometimes, when an NFS server is rebooted or off for a while, the volume will remain inactive or inaccessible and greyed out in vCenter/vSphere. To restore an inactive NFS volume in ESXi version 5.x, after obviously verifying that the NFS server is in fact up, do the following from the command line:

List the mounted volumes:

~ # esxcli storage nfs list
Volume Name Host Share Accessible Mounted Read-Only Hardware Acceleration
———– ————- —– ———- ——- ——— ———————
nfsvol1 192.168.0.251 /nfs1 false true false Unknown
nfsvol2 192.168.0.251 /nfs2 false true false Unknown

Then, remove the volumes:

~ # esxcli storage nfs remove -v nfsvol1
~ # esxcli storage nfs remove -v nfsvol2
~ # esxcli storage nfs remove -v nfsvol2

List to ensure that all inactive or accessible volumes are gone:

~ # esxcli storage nfs list

Add or mount the storage:

~ # esxcli storage nfs add -H 192.168.0.251 -s /nfs1 -v nfsvol1
~ # esxcli storage nfs add -H 192.168.0.251 -s /nfs2 -v nfsvol2

And list again to verify that the volumes are mounted:

~ # esxcli storage nfs list
Volume Name Host Share Accessible Mounted Read-Only Hardware Acceleration
———– ————- —– ———- ——- ——— ———————
nfsvol1 192.168.0.251 /nfs1 true true false Not Supported
nfsvol2 192.168.0.251 /nfs2 true true false Not Supported

Note: You can achieve the same thing by remounting the volumes through the vCenter UI, but why when the command is so much more fun? Besides, in the UI, you might get an error that doesn’t seem to happen from the command line.

mail command – modify the From address

Here is how you can send an email message from linux command line and use a different from address. This is useful in scripts that run as a user that would not necessarily manage the process or even look at or care about the email.

$ mail -s “Test Subject” me@mydomain.com — -f donotreply@mydomain.com -F ‘”Do Not Reply” ‘ < someinputfile

VMware ESXi – Common Information Model

Version: VMware ESXi 5.1 and 5.5.

To determine the hardware in your VMware ESXi host, you can access the Common Information Model (CIM) data using a VMware provided shell script when you install ESXi.

Note: You have to have ssh enabled.

I found it easiest to just run the script and search the output from the less command.

Once logged via ssh as root:

~ # /bin/cim-diagnostic.sh > tmp.fil

~ # less tmp.fil

In my case, I was looking for specific physical memory information, so I searched for PhysicalMemory.

I found the following useful to determine the categories in the output:

~ # egrep “^Dumping” tmp.fil
Dumping instances of CIM_Namespace
Dumping instances of CIM_RegisteredProfile
Dumping instances of CIM_Sensor
Dumping instances of OMC_RawIpmiSensor
Dumping instances of OMC_RawIpmiEntity
Dumping instances of CIM_ComputerSystem
Dumping instances of CIM_Chassis
Dumping instances of CIM_SoftwareIdentity
Dumping instances of CIM_Memory
Dumping instances of CIM_PhysicalMemory
Dumping instances of CIM_Processor
Dumping instances of CIM_LogRecord
Dumping instances of CIM_RecordLog
Dumping instances of CIM_EthernetPort
Dumping instances of CIM_PowerSupply
Dumping instances of CIM_PCIDevice
Dumping instances of VMware_StorageExtent
Dumping instances of VMware_Controller
Dumping instances of VMware_StorageVolume
Dumping instances of VMware_Battery
Dumping instances of VMware_SASSATAPort

Chroot vsftpd – if you must.

Tested on Ubuntu 12.04 LTS.

This should be used only for an account for ftp only, because filesystem write access will be removed.

Install vsftp:

$ sudo apt-get install vsftpd

Edit /etc/vsftpd.conf:

$ sudo cp -p /etc/vsftpd.conf /etc/vsftpd.conf.orig
$ sudo vi /etc/vsftpd.conf


# JGZ 9/3/2014 – disable anonymous
#anonymous_enable=YES
anonymous_enable=NO

# JGZ 9/3/2014 – use local accounts
local_enable=YES
#

# JGZ 9/3/2014 – allow writing
write_enable=YES
#

# JGZ 9/3/2014 – jail local user accounts in their home directory
chroot_local_user=YES
#

# JGZ 9/3/2014 – don’t allow list
chroot_list_enable=NO

# JGZ 9/3/2014 – list permission if in the file
chroot_list_file=/etc/vsftpd.chroot_list

Edit/create chroot list file:

$ sudo vi /etc/vsftpd.chroot_list

localusername

Remove write access from the localusername directory:

$ sudo chmod a-w /home/localusername

Exchange Message Tracking using EMS

Sometimes I just love linux even more. Message tracking and just plain logging in Exchange is just unbearable. I love the way it is so simple to get right to the problem a linux system.

Determining what has happened to message in Exchange is just a nightmare. It seems even worse in Exchange 2013, but I know there is a lot of information there. It would just be nice to see a simple standards based SMTP type of log. I have yet to stumble on it in the mountain of logging options in EMS.

First, you have to set the event log level. At least, I believe you do. Regardless, it is something to note here, because it could useful for troubleshooting other kind of issues.

To check the current event log levels:

[PS] C:\>Get-EventLogLevel

I highly recommend piping this out to more, because there are a lot of them. By default, almost all of the log levels are set to Lowest.

To change a log level:

[PS] C:\>Set-EventLogLevel -Identity identityname -Level newlevel

For example:

[PS] C:\>Set-EventLogLevel -Identity MSExchangeTransport\SmtpReceive -Level High

[PS] C:\>get-messagetrackinglog -start “6/6/2014 10:00:00″ -end “6/17/2014 23:59″ -recipient “recipientemailaddress” -sender “senderemailaddress” | format-list | more

Replication – Event ID: 13568

I was getting the following error in the “File Replication Service” event log in a Windows 2003 ADS environment, and replication was not working at all.

The File Replication Service has detected that the replica set “DOMAIN SYSTEM VOLUME (SYSVOL SHARE)” is in JRNL_WRAP_ERROR.

WARNING: It is possible that you can lose some data (policies and scripts). This assumes that the PDC is the machine from where all changes are made, and contains the master copies from which everything will be replicated.

I am not exactly sure this was the correct way to resolve this issue, but I do know that the Event ID 13568 and others have stopped and my policies and scripts are now replicating fine.

This is what I did to resolve the issue:

Stop the “File Replication Service” on the server that is holding your FSMO roles (PDC) and that is your master from which all of your changes are made.

Modify this following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup:

Change the value of “BurFlags” to D2 (non-authoritative restore).

Start the “File Replication Service”

Restart Netlogon

On each of the DCs:

Stop the “File Replication Service”

Modify this following registry key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup:

Change the value of “BurFlags” to D4 (authoritative restore).

Start the “File Replication Service”

Restart Netlogon

Here is a good link for more information from Microsoft, and for how to handle other such event IDs:

http://support.microsoft.com/kb/290762

Return top

INFORMATION