Visual Studio的Code Cleanup圖示不見了
最近在準備 .NET Conf 2023 Taiwan 的分享時發生一個意外,我的 Visual Studio 裡面的 Code Cleanup 圖示不見了!
最近在準備 .NET Conf 2023 Taiwan 的分享時發生一個意外,我的 Visual Studio 裡面的 Code Cleanup 圖示不見了!
因自建 Kubernetes 的關係,常常需要重灌 Ubuntu Server 做一些 PoC,每次都會做 IPv4 與 IPv6 的調整,如果重建的時間久一點,容易忘東忘西,做個筆記較實在。
我們在 LINQPad 連線資料庫時,因為某些原因,我們會採用 linq2db.LINQPad 來進行連線作業。但當你輸入完一般的連線字串,很可能會碰到一個【此憑證鏈結是由不受信任的授權單位發出的】的錯誤。
今天要測個MS SQL的東西時,啟動MS SQL容器時發生Ports are not available
錯誤。
docker run -e "ACCEPT_EULA=Y" -e "MSSQL_SA_PASSWORD=<YourStrong@Passw0rd>" -p 1433:1433 --name sql1 --hostname sql1 -d mcr.microsoft.com/mssql/server:2022-latest
c71dce344559b7e9188144b69329bdeca50e85984742d0c97ea73d3b1a40c5cf
docker: Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:1433 -> 0.0.0.0:0: listen tcp 0.0.0.0:1433: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
在公司電腦上一直有個 WSL 的問題,就是這個 WSL 無法連線網路。請 Network 同事幫忙測試後,原來是 WSL 抓不到內網的 DNS Server,造成它無法連線上網。但設好之後,如果重開 WSL 你會發現 /etc/resolv.conf
的設定每次都會還原。我有回報 WSL Issue #9074,但感覺開發團隊不怎麼理此問題。
由於公司環境的關係,此部落格上有許多關於 Proxy 的討論。對,這篇也是。簡單來說,假設我們一台 Proxy,這台 Proxy 採用帳密認證後才能使用。如果查詢相關資料,大致可以看到一般會透過以下格式來連線設定:
http://username:password@IP:Port/
Azure Container Registry 最近 GA 了一個 Artifact Cache 功能,我測試之後,Artifact Cache 完全可以解決我們長期(困擾3-5年以上)以來在混合雲環境存取外部Registry映像檔存取問題。公司有非常安全網路規劃,因此地端內網非常不易接觸外網資源,例舉來說:
a: 地端伺服器 <--> Firewall <--> MPLS <--> ACR (v) b: 地端伺服器 <--> Firewall <--> MPLS <--> hub.docker.com (x) c: 地端伺服器 <--> Firewall <--> MPLS <--> mcr.microsoft.com (x)
看到黑大的自製網站 TLS 憑證 CLI 快速檢視工具,剛好我有點處理TLS憑證的經驗,也來獻醜一下。情境是這樣,在我們B2B資料交換系統上有許多第三方廠商的TLS憑證,想當然,這些TLS憑證用於資料交換加解密,因此很重要。現行規範是一年更新一次TLS憑證,但,就是有廠商會忘記通知我們更新TLS憑證。通常知道都是已經出事了。
Robocopy 是 Robust File Copy for Windows 的簡稱。它是一支 Windows 系統內建的檔案複製、同步、搬移指令,它利用多執行緒來提高複製效能,但在高效的背後資源使用率確出奇的低。另一重點是,它提供了非常多元參數,讓管理者能非常靈活的組合出想要所需複製的檔案與行為,複製、同步、差異、鏡像都不是問題,排程、監視也有內建功能,功能之強大,我覺得完全不輸商用軟體,更重要的它是 Windows 內建也就沒有商用授權問題。但官方說明文件會讓你不知如何下手,此篇讓我們用大量範例來說明每個參數用法,教大家成為備份大師。
公司最近在內部網站開始導入使用 HTTPS,伺服器僅匯入憑證,但還不到強制使用的階段。但在測試過程發現一點點麻煩的地方,情境與網路上的有所不同。一般碰到是開發者進行開發時會用到 localhost
這個網域,而瀏覽器因為加強安全性,因此會強制進行 HTTP 重導向 HTTPS 的動作。這個動作稱為 HSTS(HTTP Strict Transport Security)。
同事入手新設備,他知道我改用winget許久,說他也想改用winget
來安裝軟體。之前新設備有將清單整理下來,就順手提供。以下是我的winget
軟體安裝清單。我本身是開發人員,因此,軟體的選擇上會偏重開發人員。在此可以先提供一小技巧,可以完整取得winget
上的軟體清單。
winget search --query "" | Out-File AllWingetList.txt
λ git pull
fatal: Authentication failed for 'https://dev.azure.com/x/y/z/'
公司某些伺服器,管理嚴緊,經過多次溝通後,才准許進行Git與Azure DevOps連線。但Git開通後馬上發現一個另一個問題,要有取Azure DevOps的服務都必須經過身份認證。是可以看到登入畫面,但礙於網路限制,你無法完成身份認證的過程。因此,不論是git pull
、git push
都卡住了。
早期因為公司網路架構問題,在地端架設的Azure DevOps Agent一直有個問題,就是我們必須手動進行更新。雖然有寫成指令碼來協助,但不能全自動化,就是覺得麻煩。
近期,架構上有所突破,我們可以採取Proxy連線的方式,來重新設定這些地端的Azure DevOps Agent,但在重新設定之後,碰到一些問題,這在整理起來。
我知道,這個題目很奇怪。原因來自於一場週未神奇的Debug之旅。
週末我們進行系統更新,其中包含了Kubernetes叢集。測試區很正常的更新完成,但正式區有個系統,在更新之後不正常,在 kubectl
看來Pod、Service都很正常,但就是會產生連線錯誤。查了好幾個小時,終於發現是核心calico-apiserver有問題,根本跟原本的Pod與Service無關。因為是Calico的問題,造成內部網路的運作不正常,心想,正式區又是核心網路,怎麼會出事呢?
我心都涼了。
上一篇,是直接透過各種 containerd CLI 來存取 Private Registry 裡的 Images。其實這只算一個 PoC,因為要先學習如何存取私有 Registry。有了之前的經驗,那麼接下來的大目標是讓 Kubernetes 的 nodes 也能存取私有 Registry。之前提到,Kubernetes 本身是使用 crictl
CLI 來與 containerd 溝通。
crictl pull --creds "UserName:Password" "ImageDetail"
但我們用 Kubernetes 時不可能這樣下指令,必須透過一些其他方法。Kubernetes 本身可以吃 docker 的 config.json 組態來使用。對「docker 的 config.json 組態」有沒有很熟悉的感覺。對,在上一篇我們透過 nerdctl login
協助,它預設會把相關組態儲存下來到 /root/.docker/config.json
,這不就是我們需要的嗎。
在安裝完containerD之後,有時需要直接與containerd溝通,這時就需要透過CLI,文件共介紹 ctr、nerdctl、crictl 三套 CLI,CLI 與 containerd 的關係,就像 dockerd 與 docker CLI 差不多意思。除了溝通之外,由於我們 Registry 是採用Azure Container Registry,因此另一個重點是要知道如何設定以存取預設 docker.io 以外的 Registry。
話說[前篇]處理好Notebook、Hyper-V網路與VM網路之間的問題之後,在MicroK8s的幫助下,從Kubernetes到Kubernetes Cluster幾乎都是一行指令就能完成。
安裝MicroK8s:
sudo snap install microk8s --classic --channel=1.25
建立與加入Cluster:
microk8s add-node
方便代表看不到細節。因為想要瞭解細節,因此又花了一些時間學習如何從無到有設定與安裝Kubernetes與建置Kubernetes Cluster。
大家好,我是此書的推坑人(見作者序)Bruce。
我在網路上的個人簡介裡有那麼一小段文字:「先後受邀加入 Study4.tw與twMVC社群講師」,STUDY4是我人生中第一個受邀加入的社群,可以說沒有社群就沒今天的我。在那個還是MSN的時代,資訊相對於台北落後的台中,有個眼光獨特且行動力超強的人Sky成立了STUDY4社群,一路看著STUDY4從一個沒沒無名的小社群,透過一場又一場的技術分享會來推廣各種技術。然後從台中殺上台北,再一次從無到有,又一次次創造及完成不可能的任務。
在Azure VM上有個高風險警告,原本以為用之前「停用不安全的TLS版本」的IISCrypto工具處理即可,以下借用黑大的PowerShell取得IISCrypto套用的結果。
PS D:\> Get-ChildItem -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers'
Hive: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Ciphers
Name Property
---- --------
AES 128/128 Enabled : 4294967295
AES 256/256 Enabled : 4294967295
DES 56/56 Enabled : 0
NULL Enabled : 0
RC2 128/128 Enabled : 0
RC2 40/128 Enabled : 0
RC2 56/128 Enabled : 0
RC4 128/128 Enabled : 0
RC4 40/128 Enabled : 0
RC4 56/128 Enabled : 0
RC4 64/128 Enabled : 0
Triple DES 168 Enabled : 4294967295
PS D:\> Get-ChildItem -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\' -Recurse |
>> ForEach-Object {
>> $p = Get-ItemProperty -Path $_.PSPath
>> if ('Enabled' -in $p.PSObject.Properties.Name) {
>> $_.PSPath.Split(':')[2]
>> "Enabled = $($p.Enabled)"
>> }
>> }
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello\Client
Enabled = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\Multi-Protocol Unified Hello\Server
Enabled = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Client
Enabled = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\PCT 1.0\Server
Enabled = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Client
Enabled = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 2.0\Server
Enabled = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client
Enabled = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server
Enabled = 0
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client
Enabled = 4294967295
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
Enabled = 4294967295
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Client
Enabled = 4294967295
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.1\Server
Enabled = 4294967295
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Client
Enabled = 4294967295
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server
Enabled = 4294967295
但沒想到前後調了幾天都沒讓它Pass,最後全部自己手動調整機碼才完成。(時間有點長是因為,調整完要等Azure去重新掃描,好像12小時才一次,因此一天調一次。)
TLS調整這部分的資訊蠻零散,修改前記得相關主題裡的注意事項要看一下,不然修改後出事,我可不負責哦。
前一篇,只是因為在Write-Debug
寫了幾個中文,浪費了大量的時間查找問題。後來黑大在FB留言一句:「好奇 .ps1 存成含 BOM 的 UTF8 編碼可避開錯誤嗎?」不試不知道,原來是我書讀的太少。將原本.ps1的UTF8改以UTF with BOM儲存後,在英文版Windows Server匯入含中文.ps1的Import-Module
立馬成功了!
故事是這樣的,我在PowerShell Core環境下開發了一個PowerShell Module。但不是每一台Windows Server都有PowerShell Core的執行環境,當部屬至Windows Server的PowerShell時才發現某些主機怪怪的。
此Module在我Windows 11開發機裡的PowerShell或PowerShell Core都有先測試過都,都能正常執行。
兩台不同的Windows Server 2019主機上,PowerShell的Import-Module
一台正常,一台不正常。而且在特定同事的開發機上也有類似的情況,也會出現匯入錯誤的情況。
最近不論內部或外部,慢慢都能看到停用TLS的資訊。順手整理一下相關資訊,以利未來要作業時可能參考。
請先參考黑大及官方文件:
第一篇一定要注意,不要搞到設定之後連RDP都連不進伺服器就好笑了。