DeBaan

2015/10/24

Office 365 recipient and group types, detailed

Group types in Office 365 are, in my opinion, quite a mess -- especially from a product specification standpoint. The use of redundant, inconsistent and conflicting terminology, and the limited applicability and/or overlap of certain group types, make it a bit hard for admins and users to wrap their heads around, to be sure.

There is a lot of overlap between recipient types and group types, so I’m including all of both. This is from clicking through the O365 interface, using test groups, etc. I believe that it is accurate as of 2015/10/24. Please let me know if you see any errors.

These are the options for both:

1. Office 365 groups (“Used for team collaboration” in O365 Admin center) (this is apparently new as of 2014)

a. Used for: usable as a security group in sharepoint (file access/sharing) and as a distro group in exchange.

b. Management

i. Created in: O365 groups are added through the OWA “Groups”; The group email address cannot be changed once established.

ii. Managed in: managed by O365 admins in O365 Admin Center > Groups, Managed by the group admins in their OWA

iii. There appear not to be email aliases (though a contact and forward could be set up elsewhere in O365)

iv. There appears to be no way to back the storage space up or recover it if a group is accidentally deleted (short of a Microsoft support request), and I've not found a way to limit examine the file storage use.

c. Rights

i. Creation: access to create is governed by O365 roles; best to have only O365 admins create groups for larger organizations.

ii. Ownership: O365 admins can assign a group “admin”

iii. Membership approval: can be by assignment, or open where anyone can join, or moderated where they request membership and it must be approved.

iv. Delivery management (Send-to): either only people within the organization, or also allow people outside the org to send to. Not sure that this can be moderated.

v. Message approval: no message approval

vi. Send-as: No

vii. Send on behalf: No

viii. Deletion: Admins can delete the group (and all content!)

d. Members: only email-enabled users

e. Content

i. Messages - All messages or “conversations” are stored in a 50 GB mailbox.

ii. Files - Includes a Sharepoint document repository for up to 5000 files.

iii. Access method: today, it’s only through the outlook web client; can be synced to workstation with Onedrive Business client.

iv. Access restrictions: group content can be private or public

1. private – only members can see the content or receive updates; but anybody can “send to” the group. The group name still shows up in some lists, though, so you wouldn’t want to use a name that disclosed a secret.

2. Public – anyone can access the content (whether a member or not), subscribe for updates, etc.

2. (Traditional) Distribution Group (“Used for mail distribution” in O365 Admin center)

a. Used for: only used in Exchange, for email. Cannot be used for file/sharing permissions.

b. Management

i. Created in: Distro groups are added in the Exchange Admin Center > Recipients > Groups

ii. Managed in: managed by O365 admins in the Exchange Admin Center > Recipients > Groups; used to be managed by group owners in OWA, not sure where this is now, or perhaps in Outlook thick client.

iii. Can have multiple email aliases

c. Rights

i. Creation: access to create is governed by O365 roles; best to have only O365 admins create groups for larger organizations.

ii. Ownership: O365 admins can manage, or can delegate to owners that are email users or email-enabled security groups

iii. Membership approval: can be open, closed, or require owner approval.

iv. Leaving group: can be open or closed

v. Delivery management (Send-to): either only people within the organization, or also allow people outside the org to send to, or allow a specific set of users or mail-enabled security groups

vi. Message approval: can be moderated (by an email user or group of moderators), and can specify senders who don’t require message approval

vii. Send-as: can delegate (recipient sees messages as coming from the group itself)

viii. Send on behalf: can delegate (recipient sees who sent message on behalf of the group)

d. Members: can be mail-users, mail-enabled contacts, email-enabled security groups, distro groups, or dynamic distro groups. (can not be O365 groups)

e. Content – There is no “group storage” for files or mailbox.

3. Dynamic Distribution group

a. Used for: only used in Exchange, for email. Cannot be used for file/sharing permissions. Dynamic distro group is like a traditional distro group, but the memberships are calculated dynamically, as each message is sent out, and is based on AD attribute values (Dept., State or province, Company, AD Custom attributes 1-13)

b. Management

i. Created in: the Exchange Admin Center > Recipients > Groups

ii. Managed in: managed by O365 admins in the Exchange Admin Center > Recipients > Groups; used to be managed by group owners in OWA, not sure where this is now

iii. Can have multiple email aliases

c. Rights

i. Creation: access to create is governed by O365 roles; best to have only O365 admins create groups for larger organizations

ii. Ownership: O365 admins can manage, or can delegate to a single owner.

iii. Membership approval: NA

iv. Delivery management (Send-to): either only people within the organization, or also allow people outside the org to send to, or allow a specific set of users or mail-enabled security groups

v. Message approval: can be moderated (by an email user or group of moderators), and can specify senders who don’t require message approval

vi. Send-as: can delegate (recipient sees messages as coming from the group itself)

vii. Send on behalf: can delegate (recipient sees who sent message on behalf of the group)

d. Members

i. Can be “all recipient types”, or

ii. Specify certain recipient types: Exchg mailboxes, mail users with external email addrs, resource mailboxes, mail contacts with external email addrs, or mail-enabled groups

4. Mail-enabled Security Group (*Called “Security Groups” in the Exchange Admin Center!*, and just like security groups “Use to assign Sharepoint permissions” in O365 Admin center! ) (think of it as a security-enabled Distribution group)

a. Used for: both Exchange email delivery, and Sharepoint/Onedrive for Business file/sharing permissions

b. Management

i. Created in :

1. Exchange Admin Center > Recipients > Groups

2. Can be pushed from Okta? (Need to verify that email address can be assigned to a security group after the fact)

ii. Managed in: managed by O365 admins in the Exchange Admin Center > Recipients > Groups; used to be managed by group owners in OWA, not sure where this is now

iii. Can have multiple email aliases

c. Rights

i. Creation: access to create is governed by O365 roles; best to have only O365 admins create groups for larger organizations

ii. Owners: O365 admins can manage, or can delegate to owners that are email users or email-enabled security groups

iii. Membership approval: can set to open (where anyone can join) or require owner approval

iv. Delivery management (Send-to): either only people within the organization, or also allow people outside the org to send to, or allow a specific set of users or mail-enabled security groups

v. Message approval: can be moderated (by an email user or group of moderators), and can specify senders who don’t require message approval

vi. Send-as: can delegate (recipient sees messages as coming from the group itself)

vii. Send on behalf: can delegate (recipient sees who sent message on behalf of the group)

d. Members: can be users, email-enabled contacts, distro groups

e. Content – no “group content” storage; mail-enabled security groups only provide for mail flow and for access to data stored elsewhere in sharepoint / onedrive for business

5. Security Group (think of it as a “pure security group”) (*not what is called a “security group” in the Exchange Admin Center! ) (like mail-enabled security groups, “Use to assign Sharepoint permissions” in O365 Admin center)

a. Used for: only used for Sharepoint/Onedrive file/sharing permissions

b. Management

i. Created in:

1. O365 Admin Center > Groups

2. can be pushed from Okta,thus from AD based on name filters set in Okta, thus can leverage existing organizational, geography, and project-based groups that have to be maintained in AD, anyway, for file and Okta app access (_org- , _proj-, _geo- groups)

ii. Managed in: managed in O365 Admin Center, or pushed from Okta

c. Rights

i. Creation: access to create is governed by O365 roles; best to have only O365 admins create groups for larger organizations

ii. Ownership: No delegation of group administration is supported

iii. Membership approval: Not supported

d. Members: can be a user (with or without mailbox), an O365 group, security group, Distro group, or email-enabled security group. (member cannot be dynamic distro group)

e. Content – no “group content” storage. Security groups only provide access to data stored elsewhere in Sharepoint / onedrive for business

6. Site Mailbox

a. I’m not clear on these, exactly; seems to be a Sharepoint site with a mailbox added to it. But “users have to be added to a sharepoint site individually in order to be able to access the site mailbox from Outlook”.

b. Seems to be inferior to Office 365 groups, and not needed.

7. Shared Mailbox

a. Used for: Exchange only, email is sent to this mailbox. Existing mail-enabled users may access the mailbox. The mailbox cannot be authenticated to directly (e.g., for POP3/IMAP/OWA)

b. Management:

i. Created in: Exchange Admin Center > Recipients > Shared

ii. Managed in: Exchange Admin Center > Recipients > Shared

iii. Can have multiple aliases

c. Rights

i. Creation: access to create is governed by O365 roles

ii. Ownership: “Full Access” can be delegated delegate to an mail-enabled user or email-enabled group

iii. Membership approval: NA

iv. Delivery management (Send-to): Can set to anyone, only authenticated users, and/or can block certain senders

v. Message approval: No

vi. Send-as: can delegate to an mail-enabled user or email-enabled group (recipient sees messages as coming from the mailbox/email address itself)

vii. Send on behalf: No

d. Membership: Shared mailboxes can belong to O365 groups, distro groups, email-enabled security groups, security groups, and perhaps dynamic distro groups.

e. Mail flow

i. Can forward or forward&store

ii. Can limit message size

f. Content

i. Messages - All messages are stored in a 50 GB mailbox.

ii. Files – No file storage; only attachments on messages

iii. Access method: OWA, pop3, imap, or Outlook client,

iv. Access restrictions: See “Ownership”

8. Email Contacts

a. Used for: Exchange only, for email forwarding or for Global Address List population

b. Management

i. Created in: Exchange Admin Center > Recipients > Contacts

ii. Managed in: Exchange Admin Center > Recipients > Contacts

iii. Can have multiple aliases

c. Delivery management (Send-to): Can set to anyone, only authenticated users, and/or can block certain senders

d. Membership: Contacts can belong to O365 groups, distro groups, email-enabled security groups, security groups, and perhaps dynamic distro groups.

9. Mailbox (Mail-enabled User)

a. Not going to elaborate

10. Resource Mailbox

a. Not going to elaborate

11. Access Definitions

a. Joining group:

i. Open: anyone can join this group without being approved by the group owners

ii. Closed: Members can be added only by the group owners. All requests to join will be rejected automatically

iii. Owner Approval: All requests are approved or rejected by the group owners

b. Leaving Group:

i. Open: Anyone can leave this group without being approved by the group owners

ii. Closed: Members can be removed only by the group owners All requests to leave will be rejected automatically

2015/08/25

Quickly check hundreds of Linux VM's for read-only filesystems

Sometimes a NAS cluster failover event for routine maintenance may take too long; or you bought the wrong storage solution; or you have a major network or SAN fault... or something else.

Any of these situations can cause your virtual machines to remount their filesystems "read-only". The proper thing (apart from fixing your infrastructure) to make your VM's more tolerant is to configure SCSI timeouts within each VM, in the case of VMware, or in the case of KVM or Xen on NFS, to change the NFS mount options. (see http://discussions.citrix.com/topic/344713-linux-vm-storage-going-read-only-on-nfs-shares-and-a-proposed-fix-in-xenserver/ for the Citrix XenServer hack.)

To detect this "read-only filesystem" rapidly, I wrote a little script I call "ckrofs". You use it as follows:

ckrofs ...
or
ckrofs `cat hostlist`

Here's the code:

#!/bin/bash

HostList=`echo ${@} | tr \\\n " "`

PARALLELISM=20

function remoteCheck()
{
   TargetHost=$1
   ThisHostOutput="### $TargetHost ###"
   ThisHostOutput+="$(ssh -q $TargetHost 'for targetfs in `mount | egrep "ext" | cut -d " " -f 3`; do touch $targetfs/foofile > /dev/null 2>&1 && rm -f $targetfs/foofile || echo -n " $targetfs appears to be readonly #"; done ' 2>&1 || echo ' unable to log in to host' )"
   echo $ThisHostOutput
}

export -f remoteCheck

echo ${HostList} | xargs -P $PARALLELISM -d" " --replace="HOST" /bin/bash -c 'remoteCheck HOST'

2015/04/30

LDAP queries for nested groups in AD

This gets all members of a domain:

ldapsearch -b "dc=mydomain,dc=com" -D "cn=myadminaccount,ou=Users,dc=mydomain,dc=com" -H ldap://mydomaincontroller/ -W -x "(objectclass=user)" cn

This gets all members (of any type) of a given group, with no recursion -- no handling of nested groups:

ldapsearch -b "dc=mydomain,dc=com" -D "cn=myadminaccount,ou=Users,dc=mydomain,dc=com" -H ldap://mydomaincontroller/ -W -x "(memberOf:=cn=mygroup,ou=groups,dc=mydomain,dc=com)" cn

This gets all objects of type "user" that belong to a given group, with no recursion -- no handling of nested groups:

ldapsearch -b "dc=mydomain,dc=com" -D "cn=myadminaccount,ou=Users,dc=mydomain,dc=com" -H ldap://mydomaincontroller/ -W -x "(&(objectclass=user)(memberOf:=cn=mygroup,ou=groups,dc=mydomain,dc=com))" cn

This gets all objects of type "user" that belong to a given group, recursing through child/nested groups:

ldapsearch -b "dc=mydomain,dc=com" -D "cn=myadminaccount,ou=Users,dc=mydomain,dc=com" -H ldap://mydomaincontroller/ -W -x "(&(objectclass=user)(memberOf:1.2.840.113556.1.4.1941:=cn=mygroup,ou=groups,dc=mydomain,dc=com))" cn

This gets all objects (groups) of which the following user is a member, recursing through child/nested groups:

ldapsearch -b "dc=mydomain,dc=com" -D "cn=myadminaccount,ou=Users,dc=mydomain,dc=com" -H ldap://mydomaincontroller/ -W -x "(member:1.2.840.113556.1.4.1941:=(cn=My User,ou=users,dc=mydomain,dc=com))" cn

(see https://msdn.microsoft.com/en-us/library/aa746475%28v=vs.85%29.aspx )

2015/04/20

Get SSL Certificate Vitals in Linux

This script will let you programmatically get a certificate start date, number of days remaining, and certificate hash, suitable for example for automated checking for expired or changed certificates, as with Zabbix:

#!/bin/bash

function printHelpTextd
{
        echo
        echo "######################################################################"
        echo "#                                                                    #"
        echo "# This script takes these parameters, in this order:                #"
        echo "# 1. check type, one of: certstartdate, certdaysleft, or certhash. #"
        echo "# 2. Host connection target (IP address or host name (fqdn)).       #"
        echo "# 3. TCP port number to connect to.                                 #"
        echo "#                                                                    #"
        echo "# This script returns, depending on the check type, one of:         #"
        echo "# - certstartdate: a text string of the cert start date             #"
        echo "# - certdaysleft: an integer of the number of days until the cert   #"
        echo "#    expiration; if the cert has expired, then a negative number.    #"
        echo "# - certhash: a hash of the cert, useful for detecting changes.     #"
        echo "#                                                                    #"
        echo "######################################################################"
        echo
}

ERR_BADNUMPARAMS=1
ERR_BADCHECKTYPE=2

# Function getCertStartDate
# parameters (ordered)
#    * Host connection target (IP address or host name (fqdn)).
#    * TCP port number to connect to.
# returns a text string of the certificate start date.
function getCertStartDate
{
        host=$1
        port=$2
        startdate=`echo quit | openssl s_client -host $host -port $port 2>/dev/null | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}' 2>/dev/null | openssl x509 -noout -dates 2>/dev/null | head -n 1 | cut -d "=" -f 2- | awk -F " " '{ print $1" "$2" "$4" "$3" "$5 }'`
        echo $startdate
}

# Function getCertDaysLeft
# parameters (ordered)
#    * Host connection target (IP address or host name (fqdn)).
#    * TCP port number to connect to.
# returns a number of days remaining
function getCertDaysLeft
{
        host=$1
        port=$2
        enddate=`echo quit | openssl s_client -host $host -port $port 2>/dev/null | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}' | openssl x509 -noout -dates 2>/dev/null | tail -n 1 | cut -d "=" -f 2-`
        formattedenddate=`echo $enddate | awk -F " " '{ print $1" "$2" "$4" "$3" "$5 }'`
        enddateseconds=`date -d "$formattedenddate" +%s`
        # expiration date minus todays date = the number of days left (in seconds)
        secondsleft=$(expr $enddateseconds - $(date +%s))
        daysleft=$(expr $secondsleft / 86400)
        echo $daysleft
}

# Function getCertHash
# parameters (ordered)
#    * Host connection target (IP address or host name (fqdn)).
#    * TCP port number to connect to.
# returns the hash of the cert, as a string
function getCertHash
{
        host=$1
        port=$2
        hash=`echo quit | openssl s_client -host $host -port $port 2>/dev/null | awk '/BEGIN/{s=x}{s=s$0"\n"}/END CERTIFICATE-----/{print s}' | openssl x509 -noout -hash 2>/dev/null`
        echo $hash
}

if [ "$#" -ne 3 ]; then
{
        echo "ERROR: Illegal number of parameters."
        printHelpText
        exit $ERR_BADNUMPARAMS
}; else
{
        Operation=$1
        TargetHost=$2
        TargetPort=$3
        case $Operation in
        certstartdate)
                getCertStartDate $TargetHost $TargetPort
                ;;
        certdaysleft)
                getCertDaysLeft $TargetHost $TargetPort
                ;;
        certhash)
                getCertHash $TargetHost $TargetPort
                ;;
        *)
                {
                        echo "ERROR: Bad check type."
                        printHelpText
                        exit $ERR_BADCHECKTYPE
                }
                ;;
        esac
}; fi

2015/04/07

Syslog on NetApp

Data Ontap has the ability to send system log messages to an industry standard syslog server (see https://library.netapp.com/ecmdocs/ECMP1196979/html/man5/na_syslog.conf.5.html)

To cause your Netapp to start logging to a syslog server named "logs.mycompany.com", you would use the wrfile to (over)write the syslog configuration file, directly from the console; leave a blank line at the end, and use ctrl-c to conclude the edit:

mynetapp> wrfile /vol/vol0/etc/syslog.conf
*.info    /dev/console
*.info    /etc/messages
*.info    @logs.mycompany.com
auth.*    @logs.mycompany.com
cmdsaudit.auditlog    @logs.mycompany.com

mynetapp>

(You should then see "syslogd restarted" shortly, when the NetApp detects the config file change.)

The "cmdsaudit.auditlog" line causes all console commands that are entered to also be logged to syslog -- thus, you have a record of who did what, when.

2015/01/21

View package changelog prior to updating

On Redhat/CentOS systems, have a look at the Yum "Changelog" plugin, "yum-plugin-changelog" or "yum-changelog" package

See “man yum-changelog”.

This lets you see what has change on a package between the version that is already installed and the latest available version.

Go to a system, and run “yum update --changelog”

Or, for a narrower view, try: “yum update kernel --changelog”

We should use this when we patch, to understand what is changing and to scope potential impact, rather than to simply “patch and pray”. Alone it is not enough (release notes should also be reviewed where available), but it is a good start and may help in flagging potential problems.

In particular, we should look at this on critical infrastructure servers, especially for those that get their software from external repositories where the software changes may be more impactful than standard RedHat/CentOS packages (which generally remain on the same version, with only back-ported bug and security fixes).

2014/12/01

Make OpenLDAP work with SSL/TLS

These instructions are for CentOS 7:

Many applications require the use of LDAP over TLS. This is also a best-practice.

However, the Linux / openldap libraries and clients now perform certificate validation. Many private enterprises will not validate "out of the box". This is how we assist it.

Take a company, "mycompany.com", with two Active Directory domain controllers, "dc1" and "dc2", and their own internal CA:

openssl s_client -host dc1.mycompany.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/
END CERTIFICATE-----/{print s}'> /etc/openldap/certs/DC1.MYCOMPANY.COM.crt

openssl s_client -host dc2.mycompany.com -port 636 | awk '/BEGIN/{s=x}{s=s$0"\n"}/
END CERTIFICATE-----/{print s}'> /etc/openldap/certs/DC2.MYCOMPANY.COM.crt

openssl s_client -showcerts -host dc1.mycompany.com -port 636
(copy the second certificate, between “BEGIN” and “END”, for the MyCompany CA into /etc/openldap/certs/MYCOMPANY_CA.crt)

cacertdir_rehash /etc/openldap/certs
This last command creates sym links named with the cert hash and pointing to the cert file for each cert in that directory.

CAVEAT EMPTOR: the certs will expire, and will (typically, in Active Directory) be automatically renewed; but your openldap clients/libraries will NOT be able to validate the renewed certs. You'll simply find that LDAP does not work anymore until you repeat this process to update the locally stored certs.

2014/10/06

XenServer boot from iSCSI

UPDATE: XenServer boot from iSCSI (at least with iBFT) is just plain awful. Don't bother. Multipath does not work. Too many hacks to try to get things to work. It is not supported, anyway, and it will probably break every time you do an upgrade. Plus, the NICs that you use for iSCSI boot will be unusable for any other purpose. This is aspect of XenServer is very immature and not robust.

Credits (Special thanks for pointers from:)

https://www.krystalmods.com/index.php?title=xenserver-6-supports-iscsi-boot-undocumented-feature&more=1&c=1&tb=1&pb=1
http://serverfault.com/questions/598773/install-xenserver-on-iscsi-target
http://serverfault.com/questions/431864/boot-from-iscsi-how-does-it-work

Notes/Warnings

This was originally writtenf or XenServer 6.2.
The NIC that is used for iSCSI boot will not be available for use for any other purposes (admin network, regular storage network, VM network, etc.)
This is with Intel I350 Gbit NICs, as on a Supermicro X9DRT motherboard, which uses the ibft module.
Once booted, you're in a Busybox environment... some commands will be limited or may not work the way in which you are accustomed on a full Linux system. Consider the information here for more troubleshooting steps to confirm that iSCSI works (LUNs are reachable, access is granted, etc.)
As a best practice, use all lower-case named target and initiator names (some firmwares may silently convert case).
WARNING: If you do not have your LUNs properly masked, do not specify the installation target correctly, and so forth, you may destroy your data. Know what you are doing, and use at your own risk.

Connect up the Intel NICs
Enable the Option ROM in the BIOS and add to the boot order; configure the iSCSI boot-enabled NICs in the NIC ROM set-up (perhaps ctrl-D when prompted after POST and prior to OS boot); You'll want to configure networking, initiator and target name; consider following these SAN best practices
Configure the iscsi target to allow access from this initiator
Boot off the CD and enter the command shell:

Insert the XenServer 6.2 CD and power on the computer. At the "boot: " prompt, type "shell" and press enter.

Prepare iscsi:

echo "InitiatorName=iqn.2014-01.local:hostname" > /etc/iscsi/initiatorname.iscsi (replace the initiator name and/or hostname as appropriate)
echo "node.session.initial_logon_retry_max = 60" >> /etc/iscsi/iscsid.conf
modprobe iscsi_ibft
modprobe scsi_transport_iscsi
modprobe iscsi_tcp
iscsid -c /etc/iscsi/iscsid.conf -i /etc/iscsi/initiatorname.iscsi -f &

set up multipath (if you have multiple paths)

modprobe dm-multipath

Start the installer

/opt/xensource/installer/init --use_ibft
(use --mpath if you have set up multipath)
(use --device_mapper_multipath=true)
(use --network_device=eth0 , or the correct iSCSI network device, if needed)

Multipath doesn't seem to "just work"... at one point, I had to do this, because if I don't, then installer runs without multipath, but when the init does switchroot, the OS hangs and complains that "a device that was previously mounted without multipath is now mounted with multipath."

Go to http://debaan.blogspot.com/2014/10/iscsi-stuff-in-busybox-on-linux.html and follow those steps to get logged in to both LUNs and get them seen with multipath.
Start the installer as before. Wait until the last step, when it says that it is ready to reboot.
Alt+F2 to get to a command shell (again).
Set up a chroot:

mount -o bind /dev /tmp/root/dev
mount -o bind /sys /tmp/root/sys
mount -o bind /proc /tmp/root/proc
chroot /tmp/root /bin/bash
cd /boot
re-run the
iscsiadm -m discovery -t sendtargets -p 10.10.10.20 commands to make the chroot environment aware of the targets
mkinitrd --with=dm-multipath --with=iscsi_ibft --with=scsi_transport_iscsi -f /boot/initrd-2.6.32.43-0.4.1.xs1.8.0.835.170778xen 2.6.32.43-0.4.1.xs1.8.0.835.170778xen

iSCSI stuff in Busybox on Linux

Notes/Warnings

This works with Intel I350 Gbit NICs, as on a Supermicro X9DRT motherboard, which uses the igb (1Gbit) or ixgbe (10Gbit) module as the NIC device driver, and the iscsi_ibft module for iscsi boot. You'll have to change the module names if using Broadcom or other chips.
Once booted, you're in a Busybox environment... some commands will be limited or may not work the way in which you are accustomed on a full Linux system.
As a best practice, use all lower-case named target and initiator names (some firmwares may silently convert case).
WARNING: If you do not have your LUNs properly masked, do not specify the installation target correctly, and so forth, you may destroy your data. Know what you are doing, and use at your own risk.

Connect up the Intel NICs
Configure the iscsi target to allow access from this initiator (hint: this is done on your SAN), and mask out other LUNs to be NOT visible to this initiator
Boot off the CD and enter the busybox command environment
Manually configure the ip address and enable the interfaces, and verify connectivity

ifconfig eth0 inet 10.10.10.15 netmask 255.255.255.0 up
route add default gw 10.10.10.1
ping 10.10.10.1; ping www.google.com
At this point you can enable ssh to access this from a different computer over the network, if you need to:

ssh-keygen -f /etc/ssh_host_rsa_key -t rsa (use an empty passphrase)
ssh-keygen -f /etc/ssh_host_dsa_key -t dsa (use an empty passphrase)
/usr/sbin/sshd
echo "root:supersecret" | chpasswd
(now, copy the hashed password for root from /etc/passwd to /etc/shadow

Prepare iscsi:

mkdir /etc/iscsi
echo "InitiatorName=iqn.2014-01.local:hostname" > /etc/iscsi/initiatorname.iscsi (replace the initiator name and/or hostname as appropriate)
echo "node.startup = automatic" > /etc/iscsi/iscsid.conf
echo "node.session.initial_logon_retry_max = 60" >> /etc/iscsi/iscsid.conf
modprobe iscsi_ibft
modprobe scsi_transport_iscsi
modprobe iscsi_tcp
iscsid -c /etc/iscsi/iscsid.conf -i /etc/iscsi/initiatorname.iscsi -f &

detect iscsi targets (where 10.10.10.20 is the IP address of the iSCSI SAN target) (only do this if you are not going to use the ibft boot stuff from an OS installer)

iscsiadm -m discovery -t sendtargets -p 10.10.10.20
iscsiadm -m node -l

set up multipath (if you have multiple paths)

modprobe dm-multipath
multipath -l -r
multipath -l -r (verify that the paths exist and are recognized...)

At this point, you can use the multipath device to access your iSCSI LUNs as needed.
If you want to run an OS installer, at this point start the installer

(in CentOS or XenServer installation media, append --use_ibft)
(use --mpath if you have set up multipath)
(use --network_device=eth0 , or the correct iSCSI network device, if needed)

2014/10/02

Storage Best Practices

Comments welcome. These are just some things I've decided work best and save hassles:

General Storage

Compression should be used on the back-end storage, not in the VM or host that is mounting the storage.
Data should be grouped in volumes based on general purpose/function, performance requirements, backup requirements, and any isolation requirements. For example:
1. DB logs should be on a separate hosting aggregate/raid-set from the databases that they help to protect.
2. General business data should not be on the same volume as Financials data, because they have distinct back-up requirements.
3. File share data and VM data should not be on the same underlying volume (though they may live on the same RAID set / aggregate.
NAS/SAN volumes and shares should be named to say as briefly as possible what they actually are:
1. Scratch/temp data should always be named such that the use can see that it is "scratch" data. e.g., "localscratch0", "nas_scratch0".
2. vi_eng_0 (virtual infrastructure for Engineering's VM's, number 0)
3. volume IT_Software shared out as \\corp.mycompany.com\LS\IT\Software.
Security
1. Permissions should be set for at least the share and directly-contained folders using domain-local security groups (using nested groups) that are specific to just that share and those folders.
2. "Everyone" should almost never be used.
3. "Deny" permissions should almost never be used; instead, create a group that includes only the desired people/roles.
Scratch data should not be backed up. Take every relevant opportunity to remind users of that.
Linux
1. LVM
  1. LVM should be used where possible -- always for the OS; for data disks it may be omitted for cases where separate LUNs are presented for data and there is only one filesystem per LUN.
  2. The OS should use a different Volume group from major application data. (simple LAMP boxes with a single disk device may us all on a single volume group; systems with more disk devices, or where one may wish to restore data LUNs from snapshot should have a separate VG_Data including all physical volumes holding application data
  3. All partitions on a single disk device should only belong to the same Volume Group. (this makes re-assembling a broken system easier... if the data volume group has a physical volume missing/broken or restored from snapshot, the system can still boot if the OS volume group is intact; then the data volume group can be re-assembled.).
  4. Logical volumes should be named with "LV" plus the mount path, substituting "_" for "/"; LV_root for the root "/" filesystem, and LV_swap for the swap filesystem.
  5. /boot should not be on a logical volume.
  6. Logical volumes should always be thick-provisioned
  7. Resizing
    1. Before any resize operation, always back up the data to external storage first!
    2. When growing a logical volume, always grow the logical volume first, using round "g" size, then resize the filesystem (don't specify a size, where possible, and let resize detect the new size). If the hosting physical volume is to be grown, grow the hosting partition/LUN and then pvextend before growing the LUN.
    3. When shrinking a logical volume, always shrink the filesystem first, using roung "g" size, then resize the logical volume, also using round "g" size specification. If the hosting partition/LUN is also to be shrunk, then it should be shrunk last using round "g" size specification.
2. Filesystems should be labeled with the mount path, e.g. "/var/log" where it fits; if the path is too long, then the last unique part of the path should be used, e.g. "postgres-backups".
Windows
1. Application Data for major applications and those where one may wish to restore data LUNs from snapshot separately from the OS should place application data on separate disk devices (not just separate partitions)
2. Filesystems should be labeled based on mount/drive path and purpose, e.g. "C_OS", "D_Data", "F_Logs", "G_MailboxDB00", "C_Appdata_logs"

General SAN

LUNs should always be masked on the SAN target device to only allow access from only those initiators who require access to that LUN.
LUNs should be formatted using the and mounted (fstab) mapped using the multipath device
Multipathing
1. Multipathing should be used where possible, with each target (redundant initiators, switches/paths, and targets)
2. Redundant targets should be used, as well: Initiator A should connect on subnet/switch A to the target LUN on SAN head A; initiator B should connect on subnet/switch B to the target LUN through SAN head B.
3. Active-active with round-robin load balancing should be used.
4. LUNs should generally be thinly provisioned (except for LUNs hosting essential databases); the monitoring system (Zabbix) should be configured to alert when the hosting aggregate is at 80, 90, and 95% of capacity..

FC

FC switches should use WWN-based zoning
Any host OS installation should include *unplugging* the HBA so that the OS does not wipe all visible LUNs. (If the host OS is being installed for boot-from-SAN, then all LUN masks and target attributes should be triple-checked to avoid inadvertent destruction of data.)
switches in separate paths should be managed separately. (Combining them into a single management domain would combine them into a single fault domain for administrative errors).
WWN's should, where be possible, be aliased all storage devices (switches and SAN) to include the hostname (and optionally a function) such that they can be easily identified, referenced, and so that all related zonings/mappings can be updated only by updating the alias itself. (For example, if an HBA must be replaced, that would invalidate all WWN-based mappings; but since we used an alias for all mappings, we just update the single alias definition that included that WWN.

iSCSI

all IQN's should always be typed as all lower-case.
Initiator IQN names should be:
1. iqn.2014-01.local:hostname[-boot]
2. The - is optional, and is only needed if there are several different initiators on a single host
3. No iscsi traffic should be routed. In other words, any given initiator should be connecting to a target on the same subnet.
Targets should be mapped using IP address, not Host name.
Jumbo frames (9000-Byte) should be used where possible.

DeBaan

2015/10/24

Office 365 recipient and group types, detailed

2015/08/25

Quickly check hundreds of Linux VM's for read-only filesystems

2015/04/30

LDAP queries for nested groups in AD

2015/04/20

Get SSL Certificate Vitals in Linux

2015/04/07

Syslog on NetApp

2015/01/21

View package changelog prior to updating

2014/12/01

Make OpenLDAP work with SSL/TLS

2014/10/06

XenServer boot from iSCSI

iSCSI stuff in Busybox on Linux

2014/10/02

Storage Best Practices

General Storage

General SAN

FC

iSCSI

Contributors

Labels

Blog Archive

Links