Category: IT

FreeNAS (Rsync over SSH) to Synology Setup

 

 

 

Data 備份好緊要！

自從Office 用FreeNAS keep Source 以黎，都係用USB HDD 經PC 行SyncBackPro 做Schedule Backup (雖然重有第三套Backup去另一隻Synology）

Reference site 好有用，但有一樣係入面無提，但自己又開頭無搞清楚嘅。就係FreeNAS 嘅 『rsync』 service-account 嘅Primary Group 要係 Wheel，Primary Group 係自己名或其他。Rsync task都唔會行得起。

SSH Keygen 唔係太難，最緊要搞清楚邊部機去邊部機(Source>Target)

Genkey 系係Source機gen，之後抄id_rsa.pub去TargetMachine ~/.ssh入面，同埋 “authorized_key” 兩個file。Permission 711

係Synology入面enable Rsync唔太複雜，但係唯一令我再伏嘅位係, Synology Rsync Service-Account需要係Admin Group Member。唔係啲話FreeNAS用SSHconnect去Synology系會照問Password。

如無特別問題就可以Trial Run。。但係太多Data去抄，結果 1.3T Data系用接近兩星期完成。

額外就係FreeNAS嘅Rsync系會unlimit bandwidth去做Sync。所以要control task 用幾多bandwidth。再之後係落返個logfile，等可無睇task有無問題

My setup

–bwlimit=1800 -vv –log-file=/path for log/rsync.log

 

Credit: Reference Article

FreeNAS Rsync setup

https://www.mattwall.co.uk/2016/04/03/rsync-to-synology-from-freenas.html

Synology Rsync setup

https://www.synology.com/en-global/knowledgebase/DSM/help/DSM/AdminCenter/file_rsync

Synology SSH Public Key

https://www.synology.com/en-global/knowledgebase/DSM/tutorial/Management/How_to_log_in_to_DSM_with_key_pairs_as_admin_or_root_permission_via_SSH_on_computers

SSH Keygen

https://www.ssh.com/ssh/keygen/

iOS Global HTTP Proxy 事件 結尾

遲咗接近三個星期先 寫呢個Post。第一個原因係自己真系吾記得。第二係係對上呢一個月發生咗啲幾令自己失望嘅對答。 對廠做嘢嘅效率，會答係極之失望。 Apple俾我（哋）嘅會答亦然。

係MDM廠，Apple 同客 嘅中間。 可以話影響好多人。 唔單止我一個俾廠Complain 好話我哋鬧佢哋嘅Support。 某程度自己已經覺得廠班Support已經俾啲Fault ticket搞到玩擺工噉濟。 單單ticket 三個星期以上仍然話 Simulate唔出Fault Symptom，經常講我哋試唔到應該係你哋問題，但又講唔出因由。 可以更差嘅係連問基本expected behaviour都可以要三星期。 一味拖仔訣。再唔系就話好難，好複雜做唔到。。。

Apple。。。點都唔肯認衰。再唔係同你講 “無見到有人報過”。。。當時開會一齊見客兜口兜面佢咁答（當人死架？）

結果係，如果唔系八月郁手做過嘢，拎出嚟講。到呢家會係變成點？

最終問題答案自己已經知。邊果衰心中有數。

呢家叫我唔系理咁多無問題。 食住花生繼續睇戲。

Exchange 2013 CBA Setup Review

溫故知新 !基於上星期Upgrade Exchange 2013 由 CU13 Upgrade 去 CU21。因為Server 係上年用特別手段Split出嚟。所以Upgrade到臨尾出視。迫於無奈要Delete兩個Exchange Website。呢個星期真正起過一隻新Server去做CAS。
過程無特別要多講因為非常順利，但係如同上年一樣，CBA先係最大難關。係再Review Article嘅途中，就睇到最進口嘅一環。就係Certificate嘅Subject係要有User嘅Email，或者Certificate嘅SAN Name有User UPN。
唔跟呢Part就會出IIS Error 403.7

Prerequisites:

You need access to a CA for client certificates. This can be a public CA solution, individual certificates from a vendor, or an Active Directory Certificate Services solution. Regardless, the following requirements must be met:

  • The user certificate must be issued for client authentication. The default User template from an AD CS server will work in this scenario.
  • The User Principal Name (UPN) for each user account must match the Subject Name field in the user’s certificate.
  • All servers must trust the entire CA trust chain. This chain includes the root CA certificate and any intermediate CA certificates. These certificates should be installed on all servers that may require them, to include (but not limited to) ISA/TMG/UAG server(s) and the Client Access Server (CAS).
  • The root CA certificate must be in the Trusted Root Certification Authorities store, and any intermediate CA certificates in the intermediate store on all of these systems. The root CA certificate, and intermediate CA certificates must also be installed on the EAS device.
  • The user’s certificate must be associated with the user’s account in Active Directory

Reference URL

https://docs.microsoft.com/en-us/exchange/plan-and-deploy/post-installation-tasks/configure-certificate-based-auth?view=exchserver-2019

https://blogs.technet.microsoft.com/exchange/2012/11/28/configure-certificate-based-authentication-for-exchange-activesync/

過程無特別要多講因為非常順利，但係如同上年一樣，CBA先係最大難關。係再Review Article嘅途中，就睇到最進口嘅一環。就係Certificate嘅Subject係要有User嘅Email，或者Certificate嘅SAN Name有User UPN。
唔跟呢Part就會出IIS Error 403.7

iOS Global HTTP Proxy 事件後續

好快又過左一個月，iOS12 亦已經外左。遺憾嘅係問題未有解決。係同客，同Apple，但係無廠出席嘅會。睇唔到Apple同MDM Vendor有心去睇個問題。雙方嘅反應互相推卸，不停話自己啲野無問題。 對自己放左咁多時間係非常失望。
係會議中。Apple亦講出就算真係確定有問題，都只會係iOS12往後到Fix。。。
呢一樣亦同廠一樣，迫客不停upgrade。。。

會議中。Apple亦講出就算真係確定有問題，都只會係iOS12往後到Fix。。。
呢一樣亦同廠一樣，迫客不停upgrade。。。

最後，只可以講 往後 自己係iOS12再試落去

iOS Device <> Global HTTP Proxy 再續

再續上回，已經接近4個星期。

係Split Brain DNS + Dual Web Server Host Proxy Pac (ASP)

經Mobile Network 駁入（External Proxy ASP file) 雖然無明覺試到問題，但當用Internal WiFi (Internal Proxy ASP file) 就終於有發現。

如之前講。係理論上，不論External 同 Internal Proxy file ，去MDM Server既traffic都係 “Direct”。 但iDevice 確實會出現 “Internet Connection lost”。呢句意思係咩？就係iOS device會係Connect住Internal WiFi，有Valid IP, GW, DNS 嘅情況之下，去唔到任何Destination。不論 External/Internal如否。睇到呢到，當然會問，係咪你WiFi 有問題，iOS device fault。

我可以講， 兩樣都無問題。係用相同WiFi, 同一部  iDevice（呢家三部試緊）。無用Global HTTP Proxy 前係非常正常。

而另一個意外發現係，係iDevice 落做Global HTTP Proxy Profile，而又未出現Connection lost之前，App updates (DEP 系 Auto-Updates)係變得非常非常之慢，係可以去到以 “小時”計，都update唔到。
就咩個發現， MobileIron 同 Apple 仍然未表態。。。

To be Cont’d

Supervised iOS device – Global HTTP Proxy profile credentials cached in device.

 

 

 

廢話小說。 呢個相信唔係新問題。

續試Global HTTP Proxy Profile嘅過程已試到出嚟。

部機用個Proxy Profile嘅USER ID/Password係MDM Retired / Power Reset仍然記住。

Apple係得嘅，呢啲Cheap Bug…

Discussion Topic opened in Apple

https://discussions.apple.com/thread/8484111

突發時件簿，Global HTTP Proxy <> iOS Device Check-In issue 更新

 

 

 

係啱啱啱唔啱個鐘頭前，就係出左上一個Post後，發現MDM Server HD 100% Full而開始Malfunction，當中整晚過程唔講，但係MDM Server reboot 過3 次。係自己成晚無瞓再回魂之後第一樣發現嘅係。 Test iOS Device 嘅 CheckIn Acknowledged，MDM Server 嘅Force CheckIn 亦正常返。。。
究竟係問題咩事，後續分解。。。。。

14：31 更新。
返到Office Check 落左Global Proxy Profile (Type Auto)嘅個部iPAD，超級古怪。
未unlock Screen時，係屋企做MDM Force Checkin return Acknowledged，但係返到Office check Squid log，其實仍然係Access Denied

部iPAD Screen unlock後亦繼續Waiting Checkin pending

 

 

 

 

More updates coming…….

iOS Supervised Device 用 Global HTTP Proxy Profile 出現MDM Device Check-In Activity 失蹤事件

 

 

 

 

續上一個Post。
pFSense加Squid Proxy已經Config 好。Proxy Pac亦已經放係Web Server。係PC Browser可以順利用到Proxy，準備工作完成。

係Apple Community入面搵到一個幾好嘅Discussion

AppProxy Provider vs Global Proxy

以自己理解，AppProxyProvider 係 MDM Vendor 嘅App Gateway或者係我哋講MDM嘅PreApp VPN Gateway，等同MobileIron 嘅 Sentry

自己嘅推斷同下面呢段Message差唔多

To start, I want to be clear about one thing: App proxy providers and the global HTTP proxy are very different things. There are lots of architectural differences (app proxy providers are plumbed in at the kernel level whereas HTTP proxies require user-level support) but an obvious behavioural difference is that an app proxy provider will see all TCP connections for a particular app, whereas a global HTTP proxy will only see HTTP[S] connections but for all apps.

AppProxy可以Handle TCP ／ UDP ，但係Global HTTP Proxy真係HTTP／HTTPS

真正問題黎啦，當MDM 推個Global HTTP Proxy Profile落去部iOS device。會唔會導致問題？

答案係。 會有問題，而要Reproduce 嘅方法亦好特別。

係iOS嘅Global HTTP Proxy Profile有兩類 。
1. Auto
2. Manual
Type Auto 係用PAC file
Type Manual 係傳統嘅Server 加Port

而自己發現，Proxy Type用 Manual 係無問題嘅，但係當Proxy Type由原本嘅 Manual轉去Auto。問題就出現。
iOS無辦法正常地去Apply Profile Update，亦影響都Device嘅正常Check-In。而因為咁，部iOS其他嘅Activity 亦會唔正常

現在階段解決方法係有，但係等Vendor reproduce 個Issue，確定係真都未遲

Reference URL

https://forums.developer.apple.com/thread/74572