├── Asterisk └── README.md ├── HomeAssistant ├── HomeAssistantTrustedSelfSigned.md └── README.md ├── OpenWRT ├── 802.1xOnOpenWRTUsingFreeRadius.md └── README.md ├── README.md └── ZFS ├── README.md └── ZFSRaidZToMirror.md /Asterisk/README.md: -------------------------------------------------------------------------------- 1 | 2 | # Asterisk 3 | 4 | Here are the currently available documents : 5 | 6 | 7 | 8 | 9 | 10 | -------------------------------------------------------------------------------- /HomeAssistant/HomeAssistantTrustedSelfSigned.md: -------------------------------------------------------------------------------- 1 | 2 | # HomeAssistant: Trusted Self-Signed Certificates (HA Mobile App + Browser) 3 | 4 | #### This is a quick guide on creating self-signed IP-backed certificates for your local HomeAssistant server that are validated by the HA Mobile App and can also be added to browsers. 5 | 6 | ##### Note that the general guidance is to generate valid domain-backed certificates and regularly update them using Let's Encrypt so use this guide as a last resort. 7 | 8 | ---- 9 | 10 | 11 | 1) Create your own CA 12 | --- 13 | 14 | On your PC use your already-installed OpenSSL (if not, install it using your preferred distro's package manager). 15 | 16 | This will create your root key, so make sure the directory you're working in is not world readable and the PC you're using is somewhat trustworthy. 17 | 18 | You will need to chose a CN/Organization Name for your Root CA and for your subsequent certificates. 19 | 20 | First, generate key curve parameters, as a curve reference for later OpenSSL commands: 21 | 22 | ``` 23 | $ openssl ecparam -out ecca.param -name secp384r1 24 | ``` 25 | 26 | Then generate your CA's EC Root (self-signed) key: 27 | ``` 28 | $ openssl req -nodes -newkey ec:ecca.param -days 3650 -x509 -sha256 -keyout ecca.key -out ecca.crt 29 | ``` 30 | 31 | This will create both a `.key` and `.crt` file in the current directory. 32 | 33 | You can also combine your Root CA key & self-signed certificate in a `.pem` format, but it's not necessarily mandatory : 34 | 35 | ``` 36 | $ cat ecca.crt ecca.key > ecca.pem 37 | ``` 38 | 39 | Make sure these files are only readable by your user (`chmod 600 ecca*`). 40 | 41 | 2) Configure the OpenSSL environment 42 | --- 43 | 44 | After that, let's prepare the Demo CA directory hierarchy so that OpenSSL knows where to put its index/revocation for generated certificates and initialize the serial number to 01 for the first signed certificate : 45 | 46 | ``` 47 | $ mkdir ./demoCA/ 48 | $ mkdir ./demoCA/certs 49 | $ mkdir ./demoCA/crl 50 | $ mkdir ./demoCA/newcerts 51 | $ mkdir ./demoCA/private 52 | $ touch ./demoCA/index.txt 53 | $ echo 01 > ./demoCA/serial 54 | ``` 55 | 56 | Then, **before** creating your HA Server's key, you will need to generate a global OpenSSL configuration file that will modify OpenSSL's behaviour for multiple commands (`ca`, `req`). 57 | 58 | Here is a suggested configuration (beware of the `` you need to replace to match your own environment). This configuration was adapted from [https://jamielinux.com/docs/openssl-certificate-authority/appendix/root-configuration-file.html](https://jamielinux.com/docs/openssl-certificate-authority/appendix/root-configuration-file.html). 59 | 60 | ``` 61 | # OpenSSL root CA configuration file. 62 | # Copy to 63 | 64 | [ ca ] 65 | # see `man ca` for options 66 | default_ca = CA_default 67 | 68 | [ CA_default ] 69 | # Directory and file locations for your Demo CA to track certificates issued/revoked. 70 | dir = 71 | certs = $dir/certs 72 | crl_dir = $dir/crl 73 | new_certs_dir = $dir/newcerts 74 | database = $dir/index.txt 75 | serial = $dir/serial 76 | RANDFILE = $dir/private/.rand 77 | 78 | # The root key and root certificate, to the ones you just created. 79 | private_key = $dir/ecca.key 80 | certificate = $dir/ecca.crt 81 | 82 | # Here you could consider adding CRL (revocation) configurations as well. 83 | #crlnumber = $dir/crlnumber 84 | #crl = $dir/crl/ca.crl.pem 85 | #crl_extensions = crl_ext 86 | #default_crl_days = 30 87 | 88 | # SHA-1 is deprecated, so use SHA-512 instead. 89 | default_md = sha512 90 | 91 | name_opt = ca_default 92 | cert_opt = ca_default 93 | default_days = 3650 # to fit your preferences 94 | preserve = no 95 | policy = policy_strict 96 | 97 | [ policy_strict ] 98 | # The root CA should only sign intermediate certificates that match. 99 | # See the POLICY FORMAT section of `man ca`. 100 | countryName = match 101 | stateOrProvinceName = match 102 | organizationName = match 103 | organizationalUnitName = optional 104 | commonName = supplied 105 | emailAddress = optional 106 | 107 | [ policy_loose ] 108 | # Allow the intermediate CA to sign a more diverse range of certificates. 109 | # See the POLICY FORMAT section of the `ca` man page. 110 | countryName = optional 111 | stateOrProvinceName = optional 112 | localityName = optional 113 | organizationName = optional 114 | organizationalUnitName = optional 115 | commonName = supplied 116 | emailAddress = optional 117 | 118 | [ v3_ca ] 119 | # Extensions for a typical CA (`man x509v3_config`). 120 | subjectKeyIdentifier = hash 121 | authorityKeyIdentifier = keyid:always,issuer 122 | basicConstraints = critical, CA:true 123 | keyUsage = critical, digitalSignature, cRLSign, keyCertSign 124 | # Ensure your usage of the `ca` command adds the right SAN 125 | subjectAltName = @alt_names 126 | 127 | [ v3_intermediate_ca ] 128 | # Extensions for a typical intermediate CA (`man x509v3_config`). 129 | subjectKeyIdentifier = hash 130 | authorityKeyIdentifier = keyid:always,issuer 131 | basicConstraints = critical, CA:true, pathlen:0 132 | keyUsage = critical, digitalSignature, cRLSign, keyCertSign 133 | 134 | [ usr_cert ] 135 | # Extensions for client certificates (`man x509v3_config`). 136 | basicConstraints = CA:FALSE 137 | nsCertType = client, email 138 | nsComment = "OpenSSL Generated Client Certificate" 139 | subjectKeyIdentifier = hash 140 | authorityKeyIdentifier = keyid,issuer 141 | keyUsage = critical, nonRepudiation, digitalSignature, keyEncipherment 142 | extendedKeyUsage = clientAuth, emailProtection 143 | 144 | [ server_cert ] 145 | # Extensions for server certificates (`man x509v3_config`). 146 | basicConstraints = CA:FALSE 147 | nsCertType = server 148 | nsComment = "OpenSSL Generated Server Certificate" 149 | subjectKeyIdentifier = hash 150 | authorityKeyIdentifier = keyid,issuer:always 151 | keyUsage = critical, digitalSignature, keyEncipherment 152 | extendedKeyUsage = serverAuth 153 | 154 | [ ocsp ] 155 | # Extension for OCSP signing certificates (`man ocsp`). 156 | basicConstraints = CA:FALSE 157 | subjectKeyIdentifier = hash 158 | authorityKeyIdentifier = keyid,issuer 159 | keyUsage = critical, digitalSignature 160 | extendedKeyUsage = critical, OCSPSigning 161 | 162 | [ req ] 163 | # Configuration for the `req` command used later 164 | default_md = sha512 165 | distinguished_name = req_distinguished_name 166 | req_extensions = req_ext 167 | x509_extensions = v3_req 168 | prompt = no 169 | 170 | [req_distinguished_name] 171 | # Note that more optional fields exist for this block (locality, etc.) 172 | C = 173 | ST = 174 | O = 175 | CN = 176 | 177 | [v3_req] 178 | keyUsage = keyEncipherment, dataEncipherment 179 | extendedKeyUsage = serverAuth 180 | # Refer to the SAN configured hereafter 181 | subjectAltName = @alt_names 182 | 183 | [req_ext] 184 | subjectAltName = @alt_names 185 | 186 | [v3_req] 187 | subjectAltName = @alt_names 188 | 189 | [alt_names] 190 | IP.1 = 191 | 192 | ``` 193 | 194 | You can save this file as `ssl.cnf` which we will refer to from now on. 195 | 196 | 197 | 3) Generate your server certificate signature request (CSR) 198 | --- 199 | 200 | Now we'll generate your HA Server's CSR ensuring that the configuration is sent as a command parameter: 201 | 202 | ``` 203 | openssl req -nodes -newkey ec:ecca.crt -sha512 -keyout server.key -out server.csr -config ssl.cnf 204 | ``` 205 | 206 | This should create the `server.key` and `server.csr` file in the current directory. 207 | You should validate that the CSR has the right `Subject Alternative Name` field using the following command: 208 | 209 | ``` 210 | openssl req -text -noout -verify -in server.csr 211 | ``` 212 | 213 | This should output your certificates detail but do validate the following exists (and matches the `CN = `). 214 | 215 | ``` 216 | Requested Extensions: 217 | X509v3 Subject Alternative Name: 218 | IP Address: 219 | ``` 220 | 221 | 4) Sign your server certificate 222 | --- 223 | 224 | Now, let's sign your CSR using your pre-created Root CA using the following command: 225 | 226 | ``` 227 | openssl ca -extensions v3_ca -days 3650 -out server.crt -in server.csr -cert ecca.crt -keyfile ecca.key -config ssl.cnf 228 | ``` 229 | 230 | This command should output the following, do validate one more time that the `commonName` and the `Subject Alternative Name` fields exist and correlate. 231 | 232 | ``` 233 | Using configuration from ssl.cnf 234 | Check that the request matches the signature 235 | Signature ok 236 | Certificate Details: 237 | 238 | ... 239 | 240 | commonName = 241 | X509v3 extensions: 242 | 243 | ... 244 | 245 | X509v3 Subject Alternative Name: 246 | IP Address: 247 | 248 | Certificate is to be certified until ... 249 | Sign the certificate? [y/n]:y 250 | 251 | 1 out of 1 certificate requests certified, commit? [y/n]y 252 | Write out database with 1 new entries 253 | Data Base Updated 254 | ``` 255 | 256 | Congrats! You're now in posession of a certificate that *could* be trusted by Android & your HA mobile App, provided the Root CA is added to the trusted root CAs. So let's do that. 257 | 258 | 5) Upload your server certificate your HA config directory 259 | --- 260 | Now you can `scp` your `.crt` and your `.key` file to your HA `/config` directory (use HA SSH add-ons to connect if you're using HA OS). Make sure they are only accessible by `root` (or the user running HA). 261 | 262 | Your `configuration.yaml` file should refer to these newly created certificates: 263 | 264 | ``` 265 | http: 266 | ssl_certificate: /config/server.crt 267 | ssl_key: /config/server.key 268 | ``` 269 | 270 | Once the files are there and configured, do restart HomeAssistant using `Developer Tools->Check Configuration` followed by `Developer Tools->Restart->Restart Home Assistant`. 271 | 272 | Since you modified the certificate, it is possible that your browser cache needs to be cleared. 273 | 274 | 6) Add your Root CA to Android Trusted CAs 275 | --- 276 | 277 | Send your `ecca.crt` file to your mobile phone (preferably using a direct USB connection). 278 | 279 | On your mobile device (Example here for Android 13), navigate to your `settings` menu. 280 | 281 | Then go to `Security & privacy -> More security settings -> Encryption & credentials -> Install a Certificate`. 282 | 283 | Chose `CA certificate`, confirm that you want to `Install anyway`, enter your device lock code, and chose the `ecca.crt` file you just sent to your phone. 284 | 285 | To validate proper installation, going back to the `Encryption & credentials` settings menu, click on the `Trusted credentials` then select the `User` tab at the top and you should see your Root CA certificated added here. 286 | 287 | 7) *Optional* Add your Trusted Root CA to your Browser Certificate Store 288 | --- 289 | 290 | Follow any of the online guides for browsers e.g. [Firefox](https://google.gprivate.com/search.php?search?q=add+root+certificate+to+mozilla+firefox). 291 | 292 | 293 | 8) Reload the Android HA Mobile App 294 | --- 295 | 296 | On your mobile device, do reload the HA App and add a new server using your URL at the IP you requested a certificate for, e.g. `https://:PORT` and if you've done everything right, the app should not complain. 297 | 298 | You can test beforehand using Android Chrome since it's leveraging the same local certificate store, it should not complain that something's wrong with the CN, CA, or anything else. 299 | -------------------------------------------------------------------------------- /HomeAssistant/README.md: -------------------------------------------------------------------------------- 1 | 2 | # HomeAssistant 3 | 4 | Here are the currently available documents : 5 | 6 | 7 | [HomeAssistant: Trusted Self-Signed Certificates (HA Mobile App + Browser)](HomeAssistantTrustedSelfSigned.md) 8 | 9 | 10 | 11 | -------------------------------------------------------------------------------- /OpenWRT/802.1xOnOpenWRTUsingFreeRadius.md: -------------------------------------------------------------------------------- 1 | 2 | # OpenWRT : 802.1x EAP-TLS using Free Radius & OpenSSL CA 3 | 4 | #### This is a quick guide on setting up certificate-based wireless 802.1x authentication on OpenWRT with FreeRADIUS and generating certificates on a desktop PC with OpenSSL Demo CA, using decent cryptographic configuration : strong curves & strong cipher suite list. 5 | 6 | ##### This guide could easily be adapted to use EAP-TTLS+EAP-TLS which was my initial intent, but most of the client UIs (Android, iOS, Windows, NetworkManager, etc.) do not propose EAP-TLS authentication when chosing EAP-TTLS connection. 7 | 8 | ##### At the time of this writing, the current version of OpenWRT is 'Barrier Breaker/14.07' and will use this as a reference, future versions should require simliar configuration with minimal modifications. 9 | 10 | ---- 11 | 12 | 13 | 1) Initial OpenWRT configuration 14 | --- 15 | 16 | Make sure you have all the OpenWRT's source repositories available in your `/etc/opkg.conf` file. 17 | 18 | ``` 19 | src/gz barrier_breaker_base http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/base 20 | src/gz barrier_breaker_luci http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/luci 21 | src/gz barrier_breaker_packages http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/packages 22 | src/gz barrier_breaker_oldpackages http://downloads.openwrt.org/barrier_breaker/14.07/ar71xx/generic/packages/oldpackages 23 | 24 | dest root / 25 | dest ram /tmp 26 | lists_dir ext /var/opkg-lists 27 | option overlay_root /overlay 28 | ``` 29 | 30 | And update your sources : 31 | 32 | ``` 33 | $ opkg update 34 | ``` 35 | 36 | Replace `wpad-mini` with `wpad` : 37 | 38 | ``` 39 | $ opkg remove wpad-mini 40 | $ opkg install wpad 41 | ``` 42 | 43 | Update the installed OpenSSL version (this should be done regularly anyways): 44 | 45 | ``` 46 | $ opkg install openssl-util libopenssl 47 | ``` 48 | 49 | Install the FreeRADIUS packages. 50 | 51 | ``` 52 | $ opkg install freeradius2 freeradius2-common freeradius2-democerts freeradius2-mod-always freeradius2-mod-attr-filter freeradius2-mod-attr-rewrite freeradius2-mod-chap freeradius2-mod-detail freeradius2-mod-eap freeradius2-mod-eap-gtc freeradius2-mod-eap-md5 freeradius2-mod-eap-mschapv2 freeradius2-mod-eap-peap freeradius2-mod-eap-tls freeradius2-mod-eap-ttls freeradius2-mod-exec freeradius2-mod-expiration freeradius2-mod-expr freeradius2-mod-files freeradius2-mod-logintime 53 | 54 | $ opkg install freeradius2-mod-mschap freeradius2-mod-pap freeradius2-mod-passwd freeradius2-mod-preprocess freeradius2-mod-radutmp freeradius2-mod-realm freeradius2-mod-sql freeradius2-mod-sql-pgsql freeradius2-mod-sql-sqlite freeradius2-mod-sqlcounter freeradius2-mod-sqllog freeradius2-utils 55 | ``` 56 | 57 | 2) Creating the EC CA 58 | --- 59 | 60 | On your Desktop PC use your already-installed OpenSSL (if not, install it using your preferred distro's package manager). 61 | 62 | This will create your root key, so make sure the directory you're working in is not world readable and the PC you're using is somewhat trustworthy. 63 | 64 | You will need to chose a CN/Organization Name for your Root CA and for your subsequent certificates. 65 | 66 | First, generate key curve parameters, as a curve reference for later OpenSSL commands: 67 | 68 | ``` 69 | $ openssl ecparam -out ecca.param -name secp384r1 70 | ``` 71 | 72 | Then generate your CA's EC Root key: 73 | ``` 74 | $ openssl req -nodes -newkey ec:ecca.param -days 3650 -x509 -sha256 -keyout ecca.key -out ecca.crt 75 | ``` 76 | 77 | Generate the server's own EC key: 78 | ``` 79 | $ openssl req -nodes -newkey ec:ecca.crt -days 3650 -sha256 -keyout serverec.key -out serverec.csr 80 | ``` 81 | 82 | Then, in order to use the OpenSSL Demo CA, you need to create the directory architecture for it and initialize the serial number to 01 for the first signed certificate : 83 | 84 | ``` 85 | $ mkdir ./demoCA/ 86 | $ mkdir ./demoCA/newcerts 87 | $ touch ./demoCA/index.txt 88 | $ echo 01 > ./demoCA/serial 89 | ``` 90 | 91 | Using OpenSSL's demo CA, sign your server's key with your Root CA key : 92 | ``` 93 | $ openssl ca -extensions v3_ca -days 3650 -out serverec.crt -in serverec.csr -cert ecca.crt -keyfile ecca.key 94 | ``` 95 | 96 | When the signing operation is complete, do verify your certificate's content using : 97 | ``` 98 | $ openssl x509 -in serverec.crt -text 99 | ``` 100 | 101 | You can also combine your Root CA key & self-signed certificate in a `.pem` format, but it's not necessarily mandatory : 102 | 103 | ``` 104 | $ cat ecca.crt ecca.key > ecca.pem 105 | ``` 106 | 107 | The same goes for the server's key signed with the EC Root CA's key : 108 | 109 | ``` 110 | $ cat serverec.crt serverec.key > serverec.pem 111 | ``` 112 | 113 | 114 | 115 | 3) Configure FreeRADIUS on OpenWRT 116 | --- 117 | 118 | First you will probably need to make sure the certificate directory exists. 119 | ``` 120 | $ mkdir /etc/freeradius/certs 121 | ``` 122 | 123 | Then SCP the necessary files over to your `/etc/freeradius/certs` directory, namely the `ca.crt` file and the `server.pem` bundle file. 124 | 125 | 126 | The configuration can now be modified, starting with the `eap.conf` file : 127 | ``` 128 | eap { 129 | ... 130 | 131 | default_eap_type = tls # Use EAP-TLS 132 | 133 | ... 134 | 135 | tls { 136 | ... 137 | 138 | private_key_password = # Empty since we did not specify one at creation in OpenSSL 139 | private_key_file = ${certdir}/server.pem 140 | certificate_file = ${certdir}/server.pem 141 | CA_file = ${cadir}/ca.pem 142 | dh_file = ${certdir}/dh2048.pem # Not really needed since we'll use ECDHE only 143 | 144 | # Decent Cipher Suite List, taken from 145 | # https://github.com/ouaibe/duraconf/blob/master/configs/nginx/nginx.COMPAT_MEDIUM_SECURITY.conf 146 | cipher_list = "ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA256:ECDHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!SRP:!DSS;" 147 | 148 | random_file = /dev/urandom # Be careful of not chosing a non-blocking random source 149 | 150 | # This selects the strongest curve available 151 | ecdh_curve = "secp384r1" 152 | 153 | ... 154 | verify { 155 | 156 | tmpdir = /tmp/radiusd # Used for caching 157 | 158 | # Set the right command to verify client certificate. 159 | client = "/usr/bin/openssl verify -CAfile /etc/freeradius2/certs/ca.pem %{TLS-Client-Cert-Filename}" 160 | 161 | } 162 | } 163 | 164 | ... 165 | 166 | } 167 | ``` 168 | 169 | Then we will modify `radiusd.conf` to add the right listening parameters : 170 | ``` 171 | listen { 172 | type = auth 173 | ipaddr = 127.0.0.1 174 | port = 0 175 | interface = lo 176 | } 177 | ``` 178 | 179 | In order to configure the security between the AP and FreeRADIUS locally on the router, first generate a long password, it can be done on your desktop PC using the following command : 180 | 181 | ``` 182 | $ apg -a 1 -m 60 -x 60 -E \'\"\` 183 | ``` 184 | 185 | And use one of the chosen passwords in your `clients.conf` file : 186 | 187 | ``` 188 | client localhost { 189 | secret = # <-- Password goes here, without quotes 190 | ipaddr = 127.0.0.1 191 | require_message_authenticator = yes 192 | nastype = other 193 | } 194 | ``` 195 | 196 | Then you need to create the authenticator logic for this site, first of all create the `localhost` site : 197 | 198 | ``` 199 | $ touch /etc/freeradius2/sites/localhost 200 | ``` 201 | 202 | And add the following configuration lines : 203 | ``` 204 | authorize { 205 | preprocess 206 | auth_log 207 | eap { 208 | ok = return 209 | } 210 | 211 | expiration 212 | logintime 213 | } 214 | 215 | authenticate { 216 | eap 217 | } 218 | 219 | preacct { 220 | preprocess 221 | suffix 222 | files 223 | } 224 | 225 | session { 226 | radutmp 227 | } 228 | 229 | post-auth { 230 | exec 231 | Post-Auth-Type REJECT { 232 | attr_filter.access_reject 233 | } 234 | } 235 | ``` 236 | 237 | Finally, edit the `radiusd` startup script (/etc/init.d/radiusd), replace or comment out the line `radiusd -i $IPADDR -p 1812,1813 $OPTIONS` with `radiusd $OPTIONS` and add the following line : 238 | 239 | ``` 240 | mkdir -p /tmp/radiusd 241 | ``` 242 | 243 | ** WARNING ** This is something you might need to re-do when updating the freeradius package on OpenWRT (since updates might replace the startup script with the original one). 244 | 245 | 4) Configure OpenWRT in 802.1x 246 | --- 247 | 248 | Edit the `/etc/config/wireless` file, and chose the right authentication mode : 249 | 250 | ``` 251 | config wifi-iface 252 | option device 'radio0' 253 | option mode 'ap' 254 | option network 'lan' 255 | option ssid '' 256 | option encryption 'wpa2+ccmp' 257 | option auth_server '127.0.0.1' # <-- Same IP as clients.conf/radiusd.conf 258 | option auth_secret '' # <-- Same long pw as clients.conf 259 | ``` 260 | 261 | Finally, you can test your config for mistakes/errors, manually starting `radiusd` as follows : 262 | 263 | ``` 264 | $ radiusd -XX 265 | ``` 266 | Errors are usually pretty self-explanatory, but be ready to pop `wireshark` if need be... 267 | 268 | 5) Manage Client Certs. 269 | --- 270 | 271 | Since we're still waiting for [let's encrypt](https://letsencrypt.org/) we'll have to manage clients certificates by hand using OpenSSL's bundled Demo CA (not production ready). 272 | 273 | Don't forget to copy your self-signed `ecca.crt` file to your different clients that need a client certificate to authenticate. 274 | 275 | Create certificates for each client using the following OpenSSL Demo CA commands : 276 | 277 | ``` 278 | $ openssl req -nodes -newkey ec:ecca.crt -days 3650 -sha256 -keyout CLIENT.key -out CLIENT.csr 279 | ``` 280 | ``` 281 | $ openssl ca -extensions v3_ca -days 3650 -out CLIENT.crt -in CLIENT.csr -cert ecca.crt -keyfile ecca.key 282 | ``` 283 | 284 | Sometimes (Android) you will need to bundle the client certificate in P12 format, use the following command to do so : 285 | ``` 286 | $ openssl pkcs12 -export -in CLIENT.crt -inkey CLIENT.key -out CLIENT.p12 -certfile ecca.crt 287 | ``` 288 | 289 | --- 290 | 291 | Sources / interesting notes : 292 | http://www.blog.10deam.com/2015/01/08/install-freeradius2-on-a-openwrt-router-for-eap-authentication/ 293 | 294 | http://blog.epijunkie.com/2013/12/freebsd-freeradius2-eap-tls-ssl-admin-a-wpa2-enterprise-guide/ 295 | 296 | https://fossjon.wordpress.com/2013/12/30/finally-able-to-run-my-own-wpa2-aes-eap-ttls-freeradius-server-raspi/ 297 | 298 | http://blog.packetheader.net/2009/06/8021x-peap-dance.html 299 | 300 | 301 | 302 | -------------------------------------------------------------------------------- /OpenWRT/README.md: -------------------------------------------------------------------------------- 1 | 2 | # OpenWRT 3 | 4 | Here are the currently available documents : 5 | 6 | 7 | [OpenWRT : 802.1x EAP-TLS using Free Radius & OpenSSL CA](802.1xOnOpenWRTUsingFreeRadius.md) 8 | 9 | 10 | 11 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # Howtos, guides & other configuration notes. 2 | 3 | ####Because why start a blog when you can markdown ? 4 | 5 | Here are the currently available documents : 6 | 7 | 8 | [OpenWRT](./OpenWRT/) 9 | 10 | [Asterisk](./Asterisk/) 11 | 12 | [ZFS](./ZFS/) 13 | 14 | [HomeAssistant](./HomeAssistant/) 15 | -------------------------------------------------------------------------------- /ZFS/README.md: -------------------------------------------------------------------------------- 1 | 2 | # ZFS 3 | 4 | Here are the currently available documents : 5 | 6 | [ZFS : Migrating a 2-Drive RaidZ-1 to a Mirror Configuration](ZFSRaidZToMirror.md) 7 | 8 | 9 | 10 | 11 | -------------------------------------------------------------------------------- /ZFS/ZFSRaidZToMirror.md: -------------------------------------------------------------------------------- 1 | 2 | # ZFS : Migrating a 2-Drive RaidZ-1 to a Mirror Configuration 3 | 4 | #### This is a risky operation that trusts ZFS's recovery feature, it is not production-ready and should only be done as a last resort. 5 | 6 | If you mistakenly created a **raidz** pool instead of a **mirror** pool and then realised there is no benefit from 2-drive raidz configuration, here are the steps you can follow in order to break the **raidz** config and transform it into a **mirror** pool, hopefully *without losing data* (no guarantee there, have backups, I'm not responsible for your data losses, etc.). 7 | 8 | 1) First, query the status of your **zpool** 9 | 10 | 11 | ``` 12 | $ zpool status 13 | ``` 14 | ``` 15 | pool: data 16 | state: ONLINE 17 | scan: none requested 18 | config: 19 | 20 | NAME STATE READ WRITE CKSUM 21 | data ONLINE 0 0 0 22 | raidz1-0 ONLINE 0 0 0 23 | disk1 ONLINE 0 0 0 24 | disk2 ONLINE 0 0 0 25 | ``` 26 | 27 | And your ZFS datasets : 28 | 29 | ``` 30 | $ zfs list 31 | ``` 32 | ``` 33 | data 1.28T 1.40T 96K none 34 | data/data 1.28T 1.40T 1.28T /data 35 | ``` 36 | 37 | 2) Then you need to chose one of the **vdevs** and put it offline, for instance, the second one : 38 | 39 | ``` 40 | $ zpool offline data disk2 41 | ``` 42 | 43 | This will effectively disable the vdev : 44 | 45 | ``` 46 | $ zpool status 47 | ``` 48 | 49 | ``` 50 | pool: data 51 | state: DEGRADED 52 | status: One or more devices has been taken offline by the administrator. 53 | Sufficient replicas exist for the pool to continue functioning in a 54 | degraded state. 55 | action: Online the device using 'zpool online' or replace the device with 56 | 'zpool replace'. 57 | scan: none requested 58 | config: 59 | 60 | NAME STATE READ WRITE CKSUM 61 | data DEGRADED 0 0 0 62 | raidz1-0 DEGRADED 0 0 0 63 | disk1 ONLINE 0 0 0 64 | disk2 OFFLINE 0 0 0 65 | 66 | 67 | errors: No known data errors 68 | ``` 69 | 70 | 3) Then comes the tricky part, you need to destroy the current pool : 71 | 72 | ``` 73 | $ zpool destroy data 74 | ``` 75 | 76 | 4) Then create a new pool using the disk you did put offline, using its full device path (here I'm using a /dev/mapper/disk2 but replace this with your own): 77 | 78 | ``` 79 | $ zpool create -O mountpoint=none -o ashift=12 -f data2 /dev/mapper/disk2 80 | ``` 81 | 82 | 5) When this is done, eventhough you destroyed the original pool, data is still present on the first **vdev**, namely *disk1*. 83 | 84 | We will now re-import this vdev as the original pool : if this steps fails, you're toast. 85 | 86 | ``` 87 | $ zpool import -D data 88 | ``` 89 | 90 | There are other parameters available for `zpool import`, make sure to read the man pages. 91 | 92 | 6) When/if this has worked, you should now have two distinct pools, the old one in degraded mode, and the new one online with a single **vdev**. 93 | 94 | ``` 95 | $ zpool list 96 | ``` 97 | ``` 98 | NAME SIZE ALLOC FREE EXPANDSZ FRAG CAP DEDUP HEALTH ALTROOT 99 | data 5.44T 2.56T 2.88T - 25% 47% 1.00x DEGRADED - 100 | data2 2.72T 324K 2.72T - 0% 0% 1.00x ONLINE - 101 | ``` 102 | 103 | And : 104 | 105 | ``` 106 | $ zpool status 107 | ``` 108 | ``` 109 | pool: data 110 | state: DEGRADED 111 | status: One or more devices has been taken offline by the administrator. 112 | Sufficient replicas exist for the pool to continue functioning in a 113 | degraded state. 114 | action: Online the device using 'zpool online' or replace the device with 115 | 'zpool replace'. 116 | scan: none requested 117 | config: 118 | 119 | NAME STATE READ WRITE CKSUM 120 | data DEGRADED 0 0 0 121 | raidz1-0 DEGRADED 0 0 0 122 | disk1 ONLINE 0 0 0 123 | disk2 OFFLINE 0 0 0 124 | 125 | errors: No known data errors 126 | 127 | pool: data2 128 | state: ONLINE 129 | scan: none requested 130 | config: 131 | 132 | NAME STATE READ WRITE CKSUM 133 | data2 ONLINE 0 0 0 134 | disk2 ONLINE 0 0 0 135 | 136 | errors: No known data errors 137 | ``` 138 | 139 | You should therefore see your datasets as follows : 140 | 141 | ``` 142 | $ zfs list 143 | ``` 144 | ``` 145 | NAME USED AVAIL REFER MOUNTPOINT 146 | data 1.28T 1.40T 96K none 147 | data/data 1.28T 1.40T 1.28T /data 148 | data2 300K 2.68T 96K none 149 | ``` 150 | 151 | 7) Now, you need to create a new dataset for the new pool (options documented in the man pages): 152 | 153 | ``` 154 | $ zfs create -o compression=lz4 data2/data 155 | $ zfs set atime=off data2/data 156 | $ zfs set mountpoint=/data2 data2/data 157 | ``` 158 | 159 | Which should give you the following results (where we can see both the old and the new datasets): 160 | 161 | ``` 162 | zfs list 163 | data 1.28T 1.40T 96K none 164 | data/data 1.28T 1.40T 1.28T /data 165 | data2 420K 2.68T 96K none 166 | data2/data 96K 2.68T 96K /data2 167 | ``` 168 | 169 | 8) Now it's time to move the data from one of the drive to the other : 170 | 171 | ``` 172 | $ mv /data/* /data2/ 173 | ``` 174 | 175 | If you have a lot of data to move you can Ctrl+Z, `bg 1`, `disown %1` in order to detach the process from the current terminal. 176 | 177 | 9) When the data has been successfully moved over, you can destroy the original pool for good : 178 | 179 | ``` 180 | $ zpool destroy data 181 | ``` 182 | 183 | 10) And then re-attach the first disk to the existing new pool : 184 | 185 | ``` 186 | $ zpool attach data2 /dev/mapper/disk2 /dev/mapper/disk1 187 | ``` 188 | 189 | Your new pool in mirror mode should be looking good, and the process of **resilvering** should have started : 190 | 191 | ``` 192 | $ zpool status 193 | ``` 194 | ``` 195 | pool: data2 196 | state: ONLINE 197 | status: One or more devices is currently being resilvered. The pool will 198 | continue to function, possibly in a degraded state. 199 | action: Wait for the resilver to complete. 200 | scan: resilver in progress since Sun Apr 26 12:55:40 2015 201 | 220M scanned out of 1.28T at 36.7M/s, 10h9m to go 202 | 216M resilvered, 0.02% done 203 | config: 204 | 205 | NAME STATE READ WRITE CKSUM 206 | data2 ONLINE 0 0 0 207 | mirror-0 ONLINE 0 0 0 208 | disk2 ONLINE 0 0 0 209 | disk1 ONLINE 0 0 0 (resilvering) 210 | 211 | errors: No known data errors 212 | ``` 213 | 214 | That's it, hoping this works out for you. 215 | 216 | 217 | --- 218 | References : 219 | https://www.mail-archive.com/zfs-discuss@opensolaris.org/msg11334.html 220 | https://pthree.org/2012/12/04/zfs-administration-part-i-vdevs/ 221 | 222 | 223 | 224 | --------------------------------------------------------------------------------