Sinan'ın Yeri

I've been using an i3 + Alacritty + Vim setup for a while, and recently spent some time getting my tmux workflow organized again. My setup is fairly simple: i3 └── Alacritty └── tmux ├── Vim ├── shell ├── SSH └── other terminal work tmux fits nicely into this setup because i3 handles the graphical windows while tmux handles the terminal environment. tmux windows I mostly use the standard tmux prefix: Ctrl-b followed by a command. Some of the shortcuts I use regularly are: Ctrl-b n next window Ctrl-b p previous window Ctrl-b l last window Ctrl-b c create a window Ctrl-b z zoom the current pane Ctrl-b d detach One small detail worth remembering is that these are two-key sequences , not simultaneous combinations. For example: Ctrl-b release z zooms the current pane. tmux sessions The session functionality is particularly useful when working with several terminal environments. Running: tmux ls shows ...

I wanted to access an Ollama server running on Fedora from another Linux machine without exposing Ollama directly to the network. Ollama was listening only on: 127.0.0.1:11434 The obvious solution was an SSH local tunnel: ssh -N -L 11434:127.0.0.1:11434 user@SERVER_IP This should make the remote Ollama API available on the client at: http://127.0.0.1:11434 However, SSH returned: channel 2: open failed: connect failed: open failed 1. Verify the service First, I confirmed that Ollama itself worked on the Fedora server: curl http://127.0.0.1:11434/api/version It returned: {"version":"0.34.0"} So Ollama was not the problem. I also checked SSH forwarding: sudo sshd -T | grep -E 'allowtcpforwarding|disableforwarding|permitopen' The relevant settings allowed forwarding: allowtcpforwarding yes disableforwarding no permitopen any 2. Check SELinux Fedora runs SELinux in enforcing mode, so I checked recent denials: sudo ausearch -m AVC -ts recent The important part was...

While setting up a headless Fedora Server, I encountered a common problem on institutional networks: Internet access required authentication through a web-based firewall portal. The server had a valid network connection and DNS resolution, but HTTPS requests failed because the firewall intercepted unauthenticated traffic. Since the machine had no graphical browser, I needed to authenticate entirely from the command line. Finding the Captive Portal A useful trick is to request a deliberately HTTP-only website: curl -v http://neverssl.com/ Instead of the expected page, the network returned JavaScript redirecting the browser to a FortiGate authentication URL: window.location="http://192.168.31.4:1000/fgtauth?<TOKEN>"; The token is important because it identifies the current authentication session. Opening that URL with curl revealed an HTML login form containing fields similar to: <form action="/" method="post"> <input type="hidden...

 What a mess I was in lately when I try to repair broken copy/paste feature on vi sessions between my computers. I used to have "+y key combination working for some machines I have, until I realised it was not working anymore.  I tried AI guidance with some progress, but it has taken a lot of time of mine. Different AIs proposed different solutions (only partial indeed) till I reached the latest stable and widespread one. The solution depends and is easily affected by the programs, their versions  and their living environments. Since I have mainly minimal servers with poorer versions of software, it was a bit tricky to find a unique solution applicable to each scenario. But I believe at last I found a simple and working one. The trick is to use the following on .vimrc for my remote hosts call plug#begin('~/.vim/plugged') Plug 'ojroques/vim-oscyank' call plug#end() let mapleader = " " if $SSH_TTY != ''    let g:oscyank_term = 'default'    l...

 On my Fedora 42 desktop I was getting errors like  julia> import Pluto ERROR: InitError: could not load library "/home/user/.julia/artifacts/1c2814ca8577e0356a6ecf8447364c19e97b86a8/lib/libssl.so" /lib64/libcrypto.so.3: version `OPENSSL_3.3.0' not found (required by /home/user/.julia/artifacts/1c2814ca8577e0356a6ecf8447364c19e97b86a8/lib/libssl.so) Stacktrace:  [1] macro expansion    @ ~/.julia/packages/JLLWrappers/m2Pjh/src/products/library_generators.jl:63 [inlined]  [2] __init__()    @ OpenSSL_jll ~/.julia/packages/OpenSSL_jll/2yAM9/src/wrappers/x86_64-linux-gnu.jl:16 during initialization of module OpenSSL_jll when I try to start Pluto from within julia. This error is somewhat related to version of the openssl libraries installed on my computer. I say so, because on my laptop I have a similar installation, but no such errors (may be due to some libraries lacking on my laptop).  Anyway, after some search (not search anymore of c...

 So much time, since my last post. Recently I was trying to find a way to compile tex files from inside vi. I have tried vim-latex plugin (which seems old) with no success. Later, I found vim-tex plugin which works. I made some modifications to .vimrc file by the help of ChatGPT and succeeded to compile Tex. And some more search enabled me compile and open as pdf my tex file with the help of zathura viewer. I had evince on my computer installed, but I wasn't able to make it open my tex files after compiling. Anyways, now it seems I can say goodbye to TexMaker and open to a new world.