2016. május 19., csütörtök

GlusterFS in a simple way

Here is the story how I managed to install a 2 node glusterfs on CentOS and one client for test purposes.
In my case the hostnames and the IPs were:

192.168.183.235 s1
192.168.183.236 s2
192.168.183.237 c1

Append these to the end of /etc/hosts to make sure that simple name resolution will work.
Execute the followings on both servers.

rpm -ivh  http://dl.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-5.noarch.rpm 
wget  -P /etc/yum.repos.d http://download.gluster.org/pub/gluster/glusterfs/3.7/3.7.5/CentOS/glusterfs-epel.repo 
yum -y install glusterfs glusterfs-fuse glusterfs-server

It's no need to install any of samba packages if you don't intend to use smb.

systemctl enable glusterd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/glusterd.service to /usr/lib/systemd/system/glusterd.service.

Both servers had a second 20G capacity disk named sdb. I created two LV's for two bricks.

[root@s2 ~]# lvcreate -L 9G -n brick2 glustervg
 Logical volume "brick2" created.
[root@s2 ~]# lvcreate -L 9G -n brick1 glustervg
 Logical volume "brick1" created.
[root@s1 ~]# vgcreate glustervg /dev/sdb
 Volume group "glustervg" successfully created
[root@s1 ~]# lvcreate -L 9G -n brick2 glustervg
 Logical volume "brick2" created.
[root@s1 ~]# lvcreate -L 9G -n brick1 glustervg
 Logical volume "brick1" created.
[root@s2 ~]# pvdisplay

  --- Physical volume ---
  PV Name               /dev/sdb
  VG Name               glustervg
  PV Size               20.00 GiB / not usable 4.00 MiB
  Allocatable           yes
  PE Size               4.00 MiB
  Total PE              5119
  Free PE               511
  Allocated PE          4608
  PV UUID               filZyX-wR7W-luFX-Asyn-fYA3-f7tf-q4xGyU
[...]

[root@s2 ~]# lvdisplay

  --- Logical volume ---
  LV Path                /dev/glustervg/brick2
  LV Name                brick2
  VG Name                glustervg
  LV UUID                Rx3FPi-S3ps-x3Z0-FZrU-a2tq-IxS0-4gD2YQ
  LV Write Access        read/write
  LV Creation host, time s2, 2016-05-18 16:02:41 +0200
  LV Status              available
  # open                 0
  LV Size                9.00 GiB
  Current LE             2304
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:3

  --- Logical volume ---
  LV Path                /dev/glustervg/brick1
  LV Name                brick1
  VG Name                glustervg
  LV UUID                P5slcZ-dC7R-iFWv-e0pY-rvyb-YrPm-FM7YuP
  LV Write Access        read/write
  LV Creation host, time s2, 2016-05-18 16:02:43 +0200
  LV Status              available
  # open                 0
  LV Size                9.00 GiB
  Current LE             2304
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:4
[...]

 

[root@s1 ~]# lvdisplay
  --- Logical volume ---
  LV Path                /dev/glustervg/brick2
  LV Name                brick2
  VG Name                glustervg
  LV UUID                7yC2Wl-0lCJ-b7WZ-rgy4-4BMl-mT0I-CUtiM2
  LV Write Access        read/write
  LV Creation host, time s1, 2016-05-18 16:01:56 +0200
  LV Status              available
  # open                 0
  LV Size                9.00 GiB
  Current LE             2304
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:2

  --- Logical volume ---
  LV Path                /dev/glustervg/brick1
  LV Name                brick1
  VG Name                glustervg
  LV UUID                X6fzwM-qdRi-BNKH-63fa-q2O9-jvNw-u2geA2
  LV Write Access        read/write
  LV Creation host, time s1, 2016-05-18 16:02:05 +0200
  LV Status              available
  # open                 0
  LV Size                9.00 GiB
  Current LE             2304
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     8192
  Block device           253:3
[...]
 

[root@s1 ~]# mkfs.xfs /dev/glustervg/brick1
 

meta-data=/dev/glustervg/brick1  isize=256    agcount=4, agsize=589824 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=2359296, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


[root@s1 ~]# mkfs.xfs /dev/glustervg/brick2

meta-data=/dev/glustervg/brick2  isize=256    agcount=4, agsize=589824 blks
         =                       sectsz=4096  attr=2, projid32bit=1
         =                       crc=0        finobt=0
data     =                       bsize=4096   blocks=2359296, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=0
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0


[root@s1 ~]# mkdir -p /gluster/brick{1,2}
[root@s2 ~]# mkdir -p /gluster/brick{1,2}
[root@s1 ~]# mount /dev/glustervg/brick1 /gluster/brick1 && mount /dev/glustervg/brick2 /gluster/brick2
[root@s2 ~]# mount /dev/glustervg/brick1 /gluster/brick1 && mount /dev/glustervg/brick2 /gluster/brick2



Add the following to a newline in both /etc/fstab:


/dev/mapper/glustervg-brick1 /gluster/brick1 xfs rw,relatime,seclabel,attr2,inode64,noquota 0 0
/dev/mapper/glustervg-brick2 /gluster/brick2 xfs rw,relatime,seclabel,attr2,inode64,noquota 0 0


[root@s1 etc]# systemctl start glusterd.service

Making sure:
[root@s1 etc]# ps ax|grep gluster

 1010 ?        Ssl    0:00 /usr/sbin/glusterd -p /var/run/glusterd.pid --log-level INFO[root@s1 etc]# gluster peer probe s2
peer probe: success.


[root@s2 etc]# gluster peer status
Number of Peers: 1
Hostname: 192.168.183.235
Uuid: f5bdc3f3-0b43-4a83-86c1-c174594566b9
State: Peer in Cluster (Connected)


[root@s1 etc]# gluster pool list
UUID                                    Hostname        State
01cf8a70-d00f-487f-875e-9e38d4529b57    s2              Connected
f5bdc3f3-0b43-4a83-86c1-c174594566b9    localhost       Connected

[root@s1 etc]# gluster volume status
No volumes present

[root@s2 etc]# gluster volume info
No volumes present

[root@s1 etc]# mkdir /gluster/brick1/mpoint1
[root@s2 etc]# mkdir /gluster/brick1/mpoint1
[root@s1 gluster]# gluster volume create myvol1 replica 2 transport tcp s1:/gluster/brick1/mpoint1 s2:/gluster/brick1/mpoint1

volume create: myvol1: failed: Staging failed on s2. Error: Host s1 is not in 'Peer in Cluster' state

Ooooops....
[root@s2 glusterfs]# ping s1ping: unknown host s1I forgot to check name resolution. When i fixed this and tried to create it again, i got:
[root@s1 glusterfs]# gluster volume create myvol1 replica 2 transport tcp s1:/gluster/brick1/mpoint1 s2:/gluster/brick1/mpoint1
volume create: myvol1: failed: /gluster/brick1/mpoint1 is already part of a volume
 
 WTF ??
[root@s1 glusterfs]# gluster volume get myvol1 all
volume get option: failed: Volume myvol1 does not exist
[root@s1 glusterfs]# gluster
gluster>
exit         global       help         nfs-ganesha  peer         pool         quit         snapshot     system::     volume
gluster> volume
add-brick      bitrot         delete         heal           inode-quota    profile        remove-brick   set            status         tier
attach-tier    clear-locks    detach-tier    help           list           quota          replace-brick  start          stop           top
barrier        create         get            info           log            rebalance      reset          statedump      sync

gluster> volume l
list  log
gluster> volume list
No volumes present in cluster

That's odd! Hmm. I thought it'd work: 
[root@s1 /]# rm /gluster/brick1/mpoint1
[root@s1 /]# gluster volume create myvol1 replica 2 transport tcp s1:/gluster/brick1/mpoint1 s2:/gluster/brick1/mpoint1volume create: myvol1: success: please start the volume to access data

[root@s1 /]# gluster volume list

myvol1

Yep. Success. Phuhh.
[root@s1 /]# gluster volume start myvol1
volume start: myvol1: success

[root@s2 etc]# gluster volume list

myvol1
[root@s2 etc]# gluster volume status
Status of volume: myvol1
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick s1:/gluster/brick1/mpoint1            49152     0          Y       2528
Brick s2:/gluster/brick1/mpoint1            49152     0          Y       10033
NFS Server on localhost                     2049      0          Y       10054
Self-heal Daemon on localhost               N/A       N/A        Y       10061
NFS Server on 192.168.183.235               2049      0          Y       2550
Self-heal Daemon on 192.168.183.235         N/A       N/A        Y       2555

Task Status of Volume myvol1
------------------------------------------------------------------------------
There are no active volume tasks

[root@s1 ~]# gluster volume create myvol2 s1:/gluster/brick2/mpoint2 s2:/gluster/brick2/mpoint2  force
volume create: myvol2: success: please start the volume to access data
[root@s1 ~]# gluster volume start myvol2
volume start: myvol2: success
[root@s1 ~]# gluster volume info
Volume Name: myvol1
Type: Replicate
Volume ID: 633b765b-c630-4007-91ca-dc42714bead4
Status: Started
Number of Bricks: 1 x 2 = 2
Transport-type: tcp
Bricks:
Brick1: s1:/gluster/brick1/mpoint1
Brick2: s2:/gluster/brick1/mpoint1
Options Reconfigured:
performance.readdir-ahead: on

Volume Name: myvol2
Type: Distribute
Volume ID: ebfa9134-0e6a-40be-8045-5b16436b88ed
Status: Started
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: s1:/gluster/brick2/mpoint2
Brick2: s2:/gluster/brick2/mpoint2
Options Reconfigured:
performance.readdir-ahead: on

On the client:

[root@c1 ~]# wget -P /etc/yum.repos.d http://download.gluster.org/pub/gluster/glusterfs/LATEST/CentOS/glusterfs-epel.repo
[...]
[root@c1 ~]# yum -y install glusterfs glusterfs-fuse
[....]
[root@c1 ~]# mkdir  /g{1,2}
[root@c1 ~]# mount.glusterfs s1:/myvol1 /g1
[root@c1 ~]# mount.glusterfs s1:/myvol2 /g2
[root@c1 ~]# mount
[...]
s1:/myvol1 on /g1 type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)
s2:/myvol2 on /g2 type fuse.glusterfs (rw,relatime,user_id=0,group_id=0,default_permissions,allow_other,max_read=131072)
[root@c1 ]# df -h
Filesystem               Size  Used Avail Use% Mounted on
/dev/mapper/centos-root   28G  1.1G   27G   4% /
devtmpfs                 422M     0  422M   0% /dev
tmpfs                    431M     0  431M   0% /dev/shm
tmpfs                    431M  5.7M  426M   2% /run
tmpfs                    431M     0  431M   0% /sys/fs/cgroup
/dev/sda1                494M  164M  331M  34% /boot
tmpfs                     87M     0   87M   0% /run/user/0
s1:/myvol1               9.0G   34M  9.0G   1% /g1 [9G,9G because of replicating (aka RAID1 over network))
s2:/myvol2                18G   66M   18G   1% /g2 (9G+9G because of distributing (aka JBOD over network))

What is the difference between distributing and striping? Here are two short sniplets from glusterhacker blog:
Distribute : A distribute volume is one, in which all the data of the volume, is distributed throughout the bricks. Based on an algorithm, that takes into account the size available in each brick, the data will be stored in any one of the available bricks. [...] The default volume type is distribute, hence my myvol2 got distributed.
Stripe: A stripe volume is one, in which the data being stored in the backend is striped into units of a particular size, among the bricks. The default unit size is 128KB, but it's configurable. If we create a striped volume of stripe count 3, and then create a 300 KB file at the mount point, the first 128KB will be stored in the first sub-volume(brick in our case), the next 128KB in the second, and the remaining 56KB in the third. The number of bricks should be a multiple of the stripe count.

The very useable official howto is here.
   
Performance test, split brain, to be continued....

2016. április 11., hétfő

A Mikrotik guest network can be more difficult than you may think

In recent RouterOS is a single click to set up a guest wifi AP. Saying guest I mean such a network that is fully or partly allowed to reach public internet but denied to reach the internal private network. Here is a simple howto about adding a second wifi AP/ slave interface. The only problem with that is it's unsecure. :( A most common way is using the QuickSet method. Everyone knows what to do seeing this window:
So if you I build a second AP like this:

it's going to use the same DHCP server as the internal WIFI. Obviously, because it's on the same bridge (switch) interface. I always wondered how they are still separeted by the RouterOS? The answer is Mikrotik's genius Layer2 firewall called Bridge filtering.

But you discover an embarassing problem if you have more IP subnets (e.g. VPN networks over pub net) and also want to accept the guest wifi filtering to them. One simply can't utilize Layer2 filtering over Layer3 routing and, of course, there is no work vice versa.

Soution: forget the built-in bridge and create a new bridge only for your guest wifi.
/interface bridge add name=bridge-guestwifi
Add a new security profile for guest if you happen to still doesn't have any:  
/interface wireless security-profiles add authentication-types=wpa2-psk mode=dynamic-keys name=guestwifi wpa2-pre-shared-key=topsecretpassword
Add your new slave interface:
 /interface wireless
add disabled=no mac-address=D6:CA:6E:4F:54:28 master-interface=wlan1 name=wlan2 security-profile=guest ssid="For Guests" wds-default-bridge=bridge-guestwifi
and link these 2 to each other.
/interface bridge port add bridge=bridge-guestwifi interface=wlan2

So far so good. Layer2 filtering is done now. But now the guests are totally separeted from your DHCP server so you need to create a new, dedicated DHCP pool for them. It requires a new address and subnet.
/ip address add address=192.168.100.1/24 interface=bridge-guest network=192.168.100.0
/ip pool add name=guest ranges=192.168.100.100-192.168.100.254
/ip dhcp-server add address-pool=guest disabled=no interface=bridge-guest name=guest
/ip dhcp-server network add address=192.168.100.0/24 dns-server=192.168.100.1 gateway=192.168.100.1

Lets suppose that you have such a source nating rule that nats anything that is going out to the internet:
In that case we have good news. You don't have to set up any more nat rule because the guest network will hit the above rule. But it's not secured yet. The following Layer3 high priority firewall rule will take care of them:
/ip firewall filter
add action=drop chain=forward in-interface=bridge-guestwifi out-interface=!ether1-gateway
So from now on, guests are denied to go anywhere but the public internet.

2016. április 7., csütörtök

Ban / reject users with freeradius based on MAC addresses

Freeradius is a common tool if someone wants to set up an enterprise WiFi authentication. But if it's in a public institude, e.g. a school, sooner or later your WiFi users' passwords will leak out and after password changes your logs get full of incorrect logins from the mischievous studends. Solution: build a script that scan the logfile for incorrect logins and ban the MAC addresses of those devices. Here is a little help on how to start thinking:
add the following to your /etc/freeradius/modules/files

files rejectmac {
                key = "%{Calling-Station-ID}"
                usersfile = ${confdir}/rejectmacaddress.txt
                compat = no
        }


add the following to authorize{} section of your /etc/freeradius/sites/sites-enabled/default

rejectmac
        if (ok) {
            reject
        }


create a new file /etc/freeradius/rejectmac.conf and add 
passwd rejectmac {
  filename = /etc/freeradius/rejectmacaddress.txt
      delimiter = ,
      format = "*Calling-Station-Id"
}


create a new file /etc/freeradius/rejectmacaddress.txt and fill it with the kiddies MACs like this
78-F8-82-F3-8F-58,B4-CE-F6-4D-74-93,B0-45-19-C6-17-D1,50-F0-D3-1D-42-CE,00-5A-05-90-08-FE,88-07-4B-D1-17-15

add this to the beginning of your radiusd.conf
$INCLUDE rejectmac.conf

restart your freeradius daemon and get ready to go home.


2016. április 6., szerda

Debian Wheezy Mail Server – Postfix Dovecot Sasl MySQL PostfixAdmin and RoundCube

Shamefully I didn't want to find my own way so the whole tutorial I followed is here.
For my personal further usage, I attached the working nginx, dovecot, postfix and php5 config to this post. There are two minor differences from the original tutorial: I don't use spam filtering because at me it's done by a 3rd party provider. Second, I use an outgoing TLS smarthost via mail submission 587 port, detailed in the postfix/main.cnf.
Note that sensitive infos are all removed and in the tgz there is a missing sock, obviously, because sockets can't be packed. (tar example/php5/fpm/socks/ssl_example.com.sock: socket ignored.)
Follow the original howto first.

Versions for my pack are:
Linux box 3.2.0-4-amd64 #1 SMP Debian 3.2.73-2+deb7u3 x86_64 GNU/Linux
ii  nginx                              1.2.1-2.2+wheezy4                 all          small, powerful, scalable web/proxy server
ii  nginx-common                       1.2.1-2.2+wheezy4                 all          small, powerful, scalable web/proxy server - common files
ii  nginx-full                         1.2.1-2.2+wheezy4                 amd64        nginx web/proxy server (standard version)
ii  dovecot-common                     1:2.1.7-7+deb7u1                  all          Transitional package for dovecot
ii  dovecot-core                       1:2.1.7-7+deb7u1                  amd64        secure mail server that supports mbox, maildir, dbox and mdbox mailboxes
ii  dovecot-gssapi                     1:2.1.7-7+deb7u1                  amd64        GSSAPI authentication support for Dovecot
ii  dovecot-imapd                      1:2.1.7-7+deb7u1                  amd64        secure IMAP server that supports mbox, maildir, dbox and mdbox mailboxes
ii  dovecot-ldap                       1:2.1.7-7+deb7u1                  amd64        LDAP support for Dovecot
ii  dovecot-lmtpd                      1:2.1.7-7+deb7u1                  amd64        secure LMTP server for Dovecot
ii  dovecot-mysql                      1:2.1.7-7+deb7u1                  amd64        MySQL support for Dovecot
ii  dovecot-pgsql                      1:2.1.7-7+deb7u1                  amd64        PostgreSQL support for Dovecot
ii  dovecot-pop3d                      1:2.1.7-7+deb7u1                  amd64        secure POP3 server that supports mbox, maildir, dbox and mdbox mailboxes
ii  dovecot-sieve                      1:2.1.7-7+deb7u1                  amd64        sieve filters support for Dovecot
ii  dovecot-sqlite                     1:2.1.7-7+deb7u1                  amd64        SQLite support for Dovecot
ii  postfix                            2.9.6-2                           amd64        High-performance mail transport agent
ii  postfix-mysql                      2.9.6-2                           amd64        MySQL map support for Postfix
ii  php5-common                        5.5.33-1~dotdeb+7.1               amd64        Common files for packages built from the php5 source
ii  php5-fpm                           5.5.33-1~dotdeb+7.1               amd64        server-side, HTML-embedded scripting language (FPM-CGI binary)
ii  php5-imap                          5.5.33-1~dotdeb+7.1               amd64        IMAP module for php5
ii  php5-intl                          5.5.33-1~dotdeb+7.1               amd64        internationalisation module for php5
ii  php5-mcrypt                        5.5.33-1~dotdeb+7.1               amd64        MCrypt module for php5
ii  p
hp5-mysql                         5.5.33-1~dotdeb+7.1               amd64        MySQL module for php5


2016. március 9., szerda

Ubiquiti Unify nuisances and the attack of the Martians

Some weeks ago I was given a nice task. A client of ours wants us to set up two new Unify APs in its network with two new wireless networks: one for guest and one for internal use. They had a Vigor 2925 to be used for firewall and DHCP role. For those who are not familiar with the wireless products named ubiquiti unify APs, here are a few links to inform:
How do I configure a "Guest Network" on UniFi AP?
Instructive reading. Based on the infos here I finally decided not to use the internal "firewall" in the APs and let the Vigor do the network separation.
UniFi - Does the controller need to be running at all times?
Official answer says "no, most of the times it is not necessary." Unfortunately this isn't entirely true with the latest firmwares. :/
No worries, since the client already had a Linux server, it looked so simple to install the controler software and setup the nodes. Sadly, everything went a different way.
For a mystical reason I couldn't make the controller software, running on the Linux, see its APs, even they were in the same subnet by their IPs and in the same broadcast domain, for the sake of Layer2 communications. I spent two days just on this riddle. Maybe it was a misconfiguration of the D-Link switches or maybe an insolvable incompatibility issue. I don't know why to this very day. :( I tried everything but the time run out so I had to find a quick solution.
So I decided to use a different network card and a second subnet on the Linux only to control the APs.
I ended up with this config:
My interfaces were:
em1       Link encap:Ethernet  HWaddr 00:25:90:xx:xx:xx
          inet addr:172.16.20.30  Bcast:172.16.20.255  Mask:255.255.255.0
          inet6 addr: fe80::225:90ff:fed3:930c/64 Scope:Link
..
em2       Link encap:Ethernet  HWaddr 00:25:90:xx:xx:xx
          inet addr:192.168.3.200  Bcast:192.168.3.255  Mask:255.255.255.0
          inet6 addr: fe80::225:90ff:fed3:930d/64 Scope:Link
..
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
..

APs looked working. I think Connected(limited) state is normal in this case. Note that I didn't use the built-in "guest network" feature because it's just ridiculous.


 So everything seemed properly set. But to my greatest astonishment I coudn't reach network share of my server lying on 172.16.20.30 from my internal wifi client 192.168.3.11. When I started to ping and tcpdump'ed on the server I saw that echo requests came in but replies never went back. I thought to myself: Seeing the fact that the kernel wanted to reply on the other interface (192.168.3.x) it's hardly surprising that it didn't work.
So I set IP policy routing: if the packet comes from 192.168.3.11 on em1, reply to it on the same interface -em1- instead of em2. You know, all the iptables mangle MARK and ip route add default via 172.16.20.1 dev em1 table ... stuff, etc. etc. etc.
It didn't work either. Suddenly a light dawned on me. I turned on kernel martian packet logging with echo 1 > /proc/sys/net/ipv4/conf/all/log_martians
and VOILA I saw:

Mar  2 20:08:03 superserver kernel: [ 2755.407570] IPv4: martian source 192.168.3.11 from 192.168.3.200, on dev em1
Mar  2 20:08:03 superserver kernel: [ 2755.407590] ll header: 00000000: ff ff ff ff ff ff 00 25 90 d3 93 0d 08 06        .......%......
Mar  2 20:08:04 superserver kernel: [ 2756.424025] IPv4: martian source 192.168.3.11 from 192.168.3.200, on dev em1
Mar  2 20:08:04 superserver kernel: [ 2756.424048] ll header: 00000000: ff ff ff ff ff ff 00 25 90 d3 93 0d 08 06        .......%......
Mar  2 20:08:05 superserver kernel: [ 2757.421639] IPv4: martian source 192.168.3.11 from 192.168.3.200, on dev em1
Mar  2 20:08:05 superserver kernel: [ 2757.421661] ll header: 00000000: ff ff ff ff ff ff 00 25 90 d3 93 0d 08 06        .......%......

It's a bit confusing isn't it ?!?! 192.168.3.200 is my own server!
I tried to turn off the Martian protection with echo 0 > /proc/sys/net/ipv4/conf/all/rp_filter
but I learned: such a bad routing problem can not be solved with a simple fix like this.
I was thinking very hard for an hour and finally I faked the kernel with an another subnet set on my second interface:

auto em2
iface em2 inet static
    address 192.168.3.200
    netmask 255.255.255.192


Now it's working as expected:
root@:/# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         172.16.20.1     0.0.0.0         UG    0      0        0 em1
172.16.20.0     0.0.0.0         255.255.255.0   U     0      0        0 em1
192.168.3.192   0.0.0.0         255.255.255.192 U     0      0        0 em2

These were all done on a:
Linux 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

2016. január 25., hétfő

Three small scrips

Hey there, long time no see. Nothing special news here, just wanted to see googlebots heading here. So here comes my first new year post, 3 minor scripts. First one is for Exchange: adds new email aliases for users from a .csv and makes it default address.

Import-Csv c:\scripts\data.csv -Header UZER,ADDRZ| Foreach{
Set-Mailbox $_.UZER -EmailAddressPolicyEnabled $false
   $user = Get-Mailbox -Identity $_.UZER
   $user.EmailAddresses+=$_.ADDRZ
   Set-Mailbox $user -PrimarySmtpAddress $_.ADDRZ
}


example of data.csv: (without any headers!)
mgibson,mel.gibson@mighty.com
ctom,tom.cruise@mighty.com
cjoe,joe.cool@mighty.com


Second one is a bit tricky. I wanted to list all my distribution groups and their members. There are lots of solutions for this, e.g. you can find an edifying blog entry here. Unfortunatelly most of these scripts don't work nowadays at Office365 Exchange because of this unpleasing nastiness:
Cannot process argument transformation on parameter 'Identity'. Cannot convert value to type "Microsoft.Exchange.Configuration.Tasks.DistributionGroupMemberIdParameter". Error: "Cannot convert hashtable to an object of the following type: Microsoft.Exchange.Configuration.Tasks.DistributionGroupMemberIdParameter. Hashtable-to-Object conversion is not supported in restricted language mode or a Data section."                                                       
Explained on reddit by PsTakuu: It's not the object being passed into the Get-DistributionGroupMember by the pipeline that is causing the issue, it's that you are shoving an entire object into the first positional parameter (Identity) and it doesn't accept hash tables.
Here's a way to recreate your issue:
Get-DistributionGroup | select -First 1 | %{Get-DistributionGroupMember $_}
Here's the way to fix:
Get-DistributionGroup | select -First 1 | %{Get-DistributionGroupMember $_.identity} 

So here is the final working solution:
foreach ($group in Get-DistributionGroup) { get-distributiongroupmember $group.displayname | ft @{expression={$_.displayname};Label="$group"}}
The results can be redirected to file like this: $( foreach (............) )|out-file file.txt
or
$result = foreach (...)
$result | out-file file.txt -append

A +1 powerlist, for bonus: 
Get-DistributionGroup|format-table -wrap -property name,emailaddresses,hiddenfromaddresslistsenabled,RequireSenderAuthenticationEnabled > c:\groups.txt

 The third supersimple linuxer script adds users to a linux system and into samba fileserver database. I don't care about real names, room numbers and so on. That also creates tricky .bat files to make it easier to attach the network drive to windows users later.

#!/bin/bash
while read line; do
uzer=$(echo $line|cut -d ':' -f1)
pazz=$(echo $line|cut -d ':' -f2)
useradd -p $(openssl passwd -1 $pazz) $uzer --shell /bin/false --no-create-home --no-user-group
echo -ne "$pazz\n$pazz\n" | smbpasswd -a -s $uzer
echo "cmdkey /add:192.168.85.254 /user:workgroup\\$uzer /pass:$pazz" > /root/batz/$uzer.bat
echo "net use m: \\\192.168.85.254\\workz /P:Yes" >> /root/batz/$uzer.bat
done < users.txt

example of users.txt:
melbigson:jydac3sS
tomcruise:hEieafS
joecool:nhi252ax


2015. november 24., kedd

LVM extension

Adding a new raid storage to an existing LVM volume. Real life example. Two new disks added to a raid mirror first.


root@mylinux:~# mdadm --create /dev/md3 --level=1 --raid-devices=2 /dev/sdd1 /dev/sde1

 root@mylinux:~# vgdisplay vg1
  --- Volume group ---
  VG Name               vg1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1.80 TiB
  PE Size               4.00 MiB
  Total PE              471654
  Alloc PE / Size       471654 / 1.80 TiB
  Free  PE / Size       0 / 0
  VG UUID               iIXHn9-h7s1-6oMw-uFvl-BJMk-Jc8N-lEBRX4

root@mylinux:~# lvdisplay vg1
  --- Logical volume ---
  LV Path                /dev/vg1/home
  LV Name                home
  VG Name                vg1
  LV UUID                CcQBbz-2GAZ-TwWm-zVva-RsRW-j1H9-L6djE6
  LV Write Access        read/write
  LV Creation host, time server, 2014-02-26 14:26:05 +0100
  LV Status              available
  # open                 1
  LV Size                1.80 TiB
  Current LE             471654
  Segments               1
  Allocation             inherit
  Read ahead sectors     auto
  - currently set to     256
  Block device           252:0

root@mylinux:~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/md2
  VG Name               vg1
  PV Size               1.80 TiB / not usable 4.81 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              471654
  Free PE               0
  Allocated PE          471654
  PV UUID               cnWVNt-iawf-fJxq-wgm9-dnmb-rB4y-ij5Oyg

  --- Physical volume ---
  PV Name               /dev/md1
  VG Name               VG0
  PV Size               18.61 GiB / not usable 4.88 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              4763
  Free PE               0
  Allocated PE          4763
  PV UUID               3QdqNr-g6yH-fnL6-5jEf-Jt1k-h03Y-2HPz0v


root@mylinux:~# pvcreate /dev/md3
  Physical volume "/dev/md3" successfully created
root@mylinux:~# pvdisplay
  --- Physical volume ---
  PV Name               /dev/md2
  VG Name               vg1
  PV Size               1.80 TiB / not usable 4.81 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              471654
  Free PE               0
  Allocated PE          471654
  PV UUID               cnWVNt-iawf-fJxq-wgm9-dnmb-rB4y-ij5Oyg

  --- Physical volume ---
  PV Name               /dev/md1
  VG Name               VG0
  PV Size               18.61 GiB / not usable 4.88 MiB
  Allocatable           yes (but full)
  PE Size               4.00 MiB
  Total PE              4763
  Free PE               0
  Allocated PE          4763
  PV UUID               3QdqNr-g6yH-fnL6-5jEf-Jt1k-h03Y-2HPz0v

  "/dev/md3" is a new physical volume of "3.64 TiB"
  --- NEW Physical volume ---
  PV Name               /dev/md3
  VG Name
  PV Size               3.64 TiB
  Allocatable           NO
  PE Size               0
  Total PE              0
  Free PE               0
  Allocated PE          0
  PV UUID               dQiWVr-yKXE-3l7s-2s1x-y8TD-E1w4-GCc8aF

root@mylinux:~# vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               1.80 TiB
  PE Size               4.00 MiB
  Total PE              471654
  Alloc PE / Size       471654 / 1.80 TiB
  Free  PE / Size       0 / 0
  VG UUID               iIXHn9-h7s1-6oMw-uFvl-BJMk-Jc8N-lEBRX4

  --- Volume group ---
  VG Name               VG0
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               18.61 GiB
  PE Size               4.00 MiB
  Total PE              4763
  Alloc PE / Size       4763 / 18.61 GiB
  Free  PE / Size       0 / 0
  VG UUID               ifFvFY-yt9A-w5g8-af3G-4Kf1-AJdn-Z7531i


root@mylinux:~# vgextend vg1
  Please enter a physical volume path
  Run `vgextend --help' for more information.
root@mylinux:~# vgextend vg1 /dev/md3
  Volume group "vg1" successfully extended
root@mylinux:~# vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  3
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               5.44 TiB
  PE Size               4.00 MiB
  Total PE              1425483
  Alloc PE / Size       471654 / 1.80 TiB
  Free  PE / Size       953829 / 3.64 TiB
  VG UUID               iIXHn9-h7s1-6oMw-uFvl-BJMk-Jc8N-lEBRX4

  --- Volume group ---
  VG Name               VG0
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               18.61 GiB
  PE Size               4.00 MiB
  Total PE              4763
  Alloc PE / Size       4763 / 18.61 GiB
  Free  PE / Size       0 / 0
  VG UUID               ifFvFY-yt9A-w5g8-af3G-4Kf1-AJdn-Z7531i


root@mylinux:~#
root@mylinux:~# lvextend -L+3.6TiB /dev/vg1/home
  Rounding size to boundary between physical extents: 3.60 TiB
  Extending logical volume home to 5.40 TiB
  Logical volume home successfully resized

  root@mylinux:~# vgdisplay
  --- Volume group ---
  VG Name               vg1
  System ID
  Format                lvm2
  Metadata Areas        2
  Metadata Sequence No  4
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                2
  Act PV                2
  VG Size               5.44 TiB
  PE Size               4.00 MiB
  Total PE              1425483
  Alloc PE / Size       1415373 / 5.40 TiB
  Free  PE / Size       10110 / 39.49 GiB
  VG UUID               iIXHn9-h7s1-6oMw-uFvl-BJMk-Jc8N-lEBRX4

  --- Volume group ---
  VG Name               VG0
  System ID
  Format                lvm2
  Metadata Areas        1
  Metadata Sequence No  2
  VG Access             read/write
  VG Status             resizable
  MAX LV                0
  Cur LV                1
  Open LV               1
  Max PV                0
  Cur PV                1
  Act PV                1
  VG Size               18.61 GiB
  PE Size               4.00 MiB
  Total PE              4763
  Alloc PE / Size       4763 / 18.61 GiB
  Free  PE / Size       0 / 0
  VG UUID               ifFvFY-yt9A-w5g8-af3G-4Kf1-AJdn-Z7531i

root@mylinux:~# xfs_growfs /dev/vg1/home
meta-data=/dev/mapper/vg1-home   isize=256    agcount=32, agsize=15092928 blks
         =                       sectsz=4096  attr=2
data     =                       bsize=4096   blocks=482973696, imaxpct=5
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0
log      =internal               bsize=4096   blocks=235827, version=2
         =                       sectsz=4096  sunit=1 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
data blocks changed from 482973696 to 1449341952


root@mylinux:~# df -h
Filesystem            Size  Used Avail Use% Mounted on
/dev/mapper/VG0-per    19G  2.5G   17G  14% /
none                  4.0K     0  4.0K   0% /sys/fs/cgroup
udev                  3.9G  4.0K  3.9G   1% /dev
tmpfs                 795M  6.5M  789M   1% /run
none                  5.0M     0  5.0M   0% /run/lock
none                  3.9G     0  3.9G   0% /run/shm
none                  100M     0  100M   0% /run/user
/dev/sdc1             3.7T  1.9T  1.8T  52% /backup
/dev/mapper/vg1-home  5.4T  1.8T  3.7T  32% /home