Sinan'ın Yeri

AI coding agents like OpenCode are powerful because they can read files, edit code, run commands, install packages, and access the internet. That also means you should think about what happens if the agent makes a mistake or executes something you didn't expect. Start with OpenCode permissions For a basic setup, use OpenCode's permission system: { "$schema": "https://opencode.ai/config.json", "permission": { "edit": "ask", "bash": "ask", "webfetch": "ask", "external_directory": "deny" } } This keeps OpenCode interactive instead of giving it unrestricted control. Don't give it your entire home directory Your home directory may contain sensitive files: ~/.ssh/ ~/.aws/ ~/.config/ .env Run OpenCode from the project it actually needs instead of giving it access to your whole $HOME . Use Bubblewrap for stronger isolation If OpenCode needs...

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...