在python裡要安裝永豐API要用的一個套件shioaji時,一直失敗,就找不到這個套件。
後來才發現,這個套件不支援自己電腦內的python3.11版。
所以就要另外裝一個python舊版的環境,目前測試是在3.8跟3.9都可以裝。
在python裡要安裝永豐API要用的一個套件shioaji時,一直失敗,就找不到這個套件。
後來才發現,這個套件不支援自己電腦內的python3.11版。
所以就要另外裝一個python舊版的環境,目前測試是在3.8跟3.9都可以裝。
最近在學Python,是直接去下載Anaconda來安裝,裝好後就有Python可以使用。
平常在寫程式是,是利用裡面已經有的SPYDER或是Jupyter notebook,在裡面編寫程式跟執行。
但最近要下載一個套件,在目前使用的Python版本裡不支援,需要用比較舊的Python才行。
這時Anaconda就有個很好用的功能,就是它可以產生不同的虛擬環境。
Anaconda剛裝好的時後,就會有預設的一個環境,搭配當下一起安裝好的Python。
如果想要用改的版本的Python,可直接建立另一個虛擬環境,選擇不同版本的Python就行了。
這時SPYDER或是Jupyter notebook還是會用預設的Python版本在執行,所以就要做一下調整。
詳細方法可以參考這篇,寫的很仔細。
https://www.modb.pro/db/194246
Recently, I've been learning Python by downloading and installing Anaconda. Once installed, Anaconda provides a Python distribution that I can use.
When writing code, I typically utilize the built-in IDEs like Spyder or Jupyter Notebook that come with Anaconda. I write and execute my code within these environments.
However, I recently needed to download a package that is not supported by the current version of Python I'm using. I needed an older version of Python for compatibility.
This is where Anaconda's useful feature comes in: it allows the creation of different virtual environments.
By default, Anaconda creates an environment with the Python version that was installed at that time.
If I want to use a different version of Python, I can simply create another virtual environment and choose the desired Python version.
In this case, Spyder or Jupyter Notebook will still use the default Python version for execution, so some adjustments need to be made.
在fortigate的防火牆上,外到內的部份有設兩條政策
政策1:外部特定IP->內部ALL->全部服務==>封鎖
政策2:外部特定IP->內部特定主機->全部服務==>封鎖
結果這個外部特定IP居然沒有在政策1就被封鎖,而是在比對到政策2時才封鎖,非常奇怪,詢問廠商才得知設定上有個地方有特別注意。
在設定外對內的政策時,因為有些內部主機有提供對外服務,有使用虛擬IP(VIP)這個功能,所以外對內的政策,內部是指定ALL的情況下,需要透過指令模式,在這個政策上加一個set match-vip enable,這個封鎖到透過VIP連進來的外部主機。
這就是為何第1條政策無效,但第2條有效的原因。
On the Fortigate firewall, there are two policies defined for inbound traffic from the outside to the inside network:
Policy 1: External specific IP -> Internal ALL -> All services ==> Block
Policy 2: External specific IP -> Internal specific host -> All services ==> Block
However, it was discovered that the external specific IP was not blocked by Policy 1 but was blocked when matched with Policy 2, which seemed strange. Upon contacting the vendor, it was revealed that there was a particular setting that required attention.
When configuring the inbound policies from external to internal, there were internal hosts that provided services to the outside using Virtual IP (VIP) functionality. Therefore, in the case where the internal field is set to ALL, an additional command "set match-vip enable" needs to be added to this policy in command mode. This command ensures that external hosts connecting through VIP are also blocked.
This explains why Policy 1 was ineffective while Policy 2 remained effective.
有些網頁必須要用IE才能正常顯示,如果透過EDGE,就要啟用裡面的IE模式才行。
可以直接在EDGE設定中加入要用IE模式開起的網頁,但這有個缺點,要一台一台做,而且還有期限,預設30天,最長可以改到90天,不適合在公司裡這樣設定。
這時就可以用GPO來佈署,步驟如下:
1. 確認GPO裡有EDGE設定,因為DC都是2012版的,所以要自己下載ADMX檔來增加EDGE功能,方式可參考 https://www.anoopcnair.com/download-microsoft-edge-admx-group-policy-templates/
2. GPO裡有EDGE設定後,要啟用兩個設定
設定企業模式網站清單-這個先設定好檔案路徑跟檔名,例如
C:\ielist.xml,這個檔案在第3步會產生。
再來是要啟用設定InternetExplorer整合。
今天把一台esxi的虛擬機做還原後,開機出現錯誤,錯誤代碼是0xC0000017,還說什麼系統檔案可能有錯誤,安全模式或回複到上次正常啟動都沒用。
最後就進設定看,發現,記憶體設定只有16m,好小啊,調成16g後,就可以正常開機了,虛驚一場。
Unable to Boot Win Virtual Machine - Error 0xC0000017
Today, after restoring a virtual machine on ESXi, I encountered an error during the boot process. The error code was 0xC0000017, indicating a possible issue with the system files. I tried starting in Safe Mode and even attempted to revert to the last known good configuration, but none of these options resolved the problem.
In a final attempt to troubleshoot, I accessed the settings and discovered that the memory allocation was set to a mere 16MB. It was a surprisingly low value. After adjusting it to 16GB, the virtual machine was able to boot up successfully. It turned out to be a false alarm, and the issue was resolved.
今年基本上就是慘,前11個月,好像只有一個月是有獲利,其他都賠錢。
12月開始把交易條件訂的比較高,所以交易次數不多,雖然前兩週都只做1口單賣當沖,但至少都有賺,第三週目前確定是沒交易機會了,希望剩下兩週也能順一點,至少讓我最後一個月也是獲利結束今年,把希望寄託在明年。
用SQUID架好Proxy Server後,都蠻順利的,開網站,用LINE,SKYPE等外部的程式都正常。
但要開啟內部的https網站時,就會無法顯示,錯誤訊息會說"網頁可能暫時離線,或是已經遷移到另一個網址"。
在access log裡查到的紀錄都是 "NONE/503 0 CONNECT"。
然後就開始上網到處查,然後有看到有些人提到在squid.conf 裡要加入一行"dns_v4_first on",雖然感覺這跟我的問題不相關,但就試試吧。
結果在conf裡先搜尋dns的字眼時,看到了這段,"dns_nameservers 8.8.8.8 208.67.222.222"。
DNS居然是指向外部,所以就把內部的DNS SERVER IP加到最前面,重啟服務,就解決這個問題了。
SQUID Proxy Unable to Connect to Internal HTTPS Websites - NONE/503 0 CONNECT
After setting up the SQUID Proxy Server, everything seemed to be working smoothly. Websites loaded fine, and external applications like LINE and Skype functioned properly. However, when trying to access internal HTTPS websites, they would not display, and an error message stating "The webpage might be temporarily down or may have moved to a new address" would appear.
Upon checking the access log, the recorded entries were "NONE/503 0 CONNECT."
I started searching online for a solution and came across a suggestion to add the line "dns_v4_first on" to the squid.conf file. Although it didn't seem directly related to my issue, I decided to give it a try.
While searching for the term "dns" in the configuration file, I came across the following line: "dns_nameservers 8.8.8.8 208.67.222.222."
To my surprise, the DNS servers were pointing to external addresses. So, I added the IP address of the internal DNS server to the beginning of the list, restarted the service, and the problem was resolved.
一台QNAP TS-432XU(4.3.6)有4顆硬碟做RAID5,最後一顆硬碟已出現警告建議更換,雖然還可以用,但這顆硬碟的讀寫速度慢很多,所以影響到一些日常作業。
原本同型號的硬碟停產了,所以就買一個同廠牌同容量,但轉速更快的來換。
雖然知道是熱插拔,但一開始還上網看一下是不是要在管理介面上做什麼操作,後來查到的畫面又跟自己的不同,就決定直接插拔更換了。
插上後系統就自己在重建了,蠻方便的,剩下就讓它跑完重建程序了。
在QNAP NAS設定好電子郵件設定,用來發送警告信給管理者,設定好後測試,卻都失敗,錯誤訊息就是示"Failed to send a test message using SMTP Service."。
從不同網段連到QNAP的管理web都正常,所以就覺得網路設定都沒問題。
後來就想用ssh連上QNAP,去ping在不同網段的mail server,卻是不通的,然後再執行route -n 顯示路由表時,卻沒有0.0.0.0的路由,這就妙了。
本來想直接用指令去加,但查到的指令route add default gw 192.168.24.1 br0有錯誤,所以就決定回管理web上看看是不是少設了什麼。
結果發現了一個東西,有一個系統預設閘道的設定,之前都沒去理它,後來進去這設定,在把gateway設定上去之後,回到ssh裡,route -n 顯示路由表時,就有0.0.0.0的路由,發送信件的功能也就正常了。
在AD查看被鎖定的帳號,用id 4776去撈出登入出敗的訊息,要找出是在哪台電腦做登入行為的。
結果在來源工作站的資訊,是一台沒看到的電腦名稱,也ping不到,覺得很奇怪。
就想到之前遇到來源工作站是空白的問題,那時就繼續在事件檢視器裡去找NTLM的log,可以找到相關的訊息。
這次也想說去NTLM裡面找找,就找到了,在NTLM裡記錄的登入失敗log裡,除了來源工作站,還多了一個安全通道名稱,這邊顯示的才是正確的電腦名稱。
至於為啥來源工作站是一個奇怪的名稱,目前也不知原因。
When checking the locked accounts in Active Directory, I used ID 4776 to retrieve the information about failed logins in order to determine the workstation where the login attempts originated.
The result showed an error in the workstation information, indicating a computer name that I couldn't find or ping, which seemed unusual.
I recalled a previous encounter where the workstation information was blank, so I continued searching for NTLM logs in the Event Viewer, as they often contain relevant details.
This time, I decided to check the NTLM logs and successfully found the failed login log. In addition to the workstation information, there was also a security channel name recorded. The computer name displayed in this section was the correct one.
As for why the workstation information appeared as a strange name, I am currently unaware of the underlying reason.