gitea/blog
Archived
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

[modify] complete the content of posts

Browse Source
This commit is contained in:
git 2023-06-03 19:55:34 +08:00
parent 6b53719306
commit 9c62d01062
2 changed files with 7 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
_posts/2023-01-18-samba.md
View File

@ -42,6 +42,8 @@ Samba服务是一种比较简单的服务配置，可以通过`apt install samba
``` ```
mask 权限，指的是用户或群组能拥有的最大 ACL 权限，也就是说，给用户或群组设定的 ACL 权限不能超过 mask 规定的权限范围，超出部分做无效处理。 mask 权限，指的是用户或群组能拥有的最大 ACL 权限，也就是说，给用户或群组设定的 ACL 权限不能超过 mask 规定的权限范围，超出部分做无效处理。
使用之前，首先需要使用`smbpasswd -a username`，将用户加入Samba组，然后使用`smbpasswd username`设定访问密码，设定空密码测试无法登录，所以最好设定一个密码登录使用。
## 三、配置Windows连接 ## 三、配置Windows连接
服务端配置完毕之后，获取服务器局域网IP，以192.168.1.107为例，在Windows下，`Win+R`输入`\\192.168.1.107`回车，在windows主机上访问时，第一次，弹出输入用户名密码对话框，进入可以正常浏览到Samba服务器共享的文件夹，包括用户主目录。当修改过`/etc/samba/smb.conf`或者调整其他配置后，重新启动服务，再在Windows里面查看时，输入用户密码后会有弹出**拒绝访问**对话框，因为windows在用ip访问机器时，一般都是以一个默认的用户来连接访问的。所以，先要删除原来的连接信息，再重新连接。 服务端配置完毕之后，获取服务器局域网IP，以192.168.1.107为例，在Windows下，`Win+R`输入`\\192.168.1.107`回车，在windows主机上访问时，第一次，弹出输入用户名密码对话框，进入可以正常浏览到Samba服务器共享的文件夹，包括用户主目录。当修改过`/etc/samba/smb.conf`或者调整其他配置后，重新启动服务，再在Windows里面查看时，输入用户密码后会有弹出**拒绝访问**对话框，因为windows在用ip访问机器时，一般都是以一个默认的用户来连接访问的。所以，先要删除原来的连接信息，再重新连接。
@ -60,6 +62,8 @@ OK \\192.168.1.107\wd Microsoft Windows Network
C:\Users\Administrator>net use \\192.168.1.107\wd /delete C:\Users\Administrator>net use \\192.168.1.107\wd /delete
# OR
C:\Users\Administrator>net use * /delete
... ...
``` ```

4
_posts/2023-05-25-gitea.md
View File

@ -147,7 +147,9 @@ systemctl start gitea.service
默认`app.ini`配置文件中，监听的ssh端口是22，原来使用frp透传ssh访问的时候，用的是VPS的54321端口，所以使用ssh进行`clone/push/pull`操作的时候实际访问的是VPS的22端口，但是VPS上既没有gitea用户，也没有gitea服务，自然就会失败。这个时候有两种解决方案：一种是将VPS的22端口作为frp的ssh转发端口，VPS本身的ssh端口修改成其他的；另一种方案是，在VPS上配置gitea服务，则什么问题都没有。 默认`app.ini`配置文件中，监听的ssh端口是22，原来使用frp透传ssh访问的时候，用的是VPS的54321端口，所以使用ssh进行`clone/push/pull`操作的时候实际访问的是VPS的22端口，但是VPS上既没有gitea用户，也没有gitea服务，自然就会失败。这个时候有两种解决方案：一种是将VPS的22端口作为frp的ssh转发端口，VPS本身的ssh端口修改成其他的；另一种方案是，在VPS上配置gitea服务，则什么问题都没有。
很显然，使用后者不切实际，这里采用的是前者的方案，修改好之后ssh还是无法执行`clone/push/pull`等操作，最终还是在issue中找到了问题所在，需要先执行一下图示的两个任务，后面就很顺利的使用ssh的功能了。 很显然，使用后者不切实际，这里采用的是前者的方案，修改好之后ssh还是无法执行`clone/push/pull`等操作，最终还是在issue中找到了问题所在，需要先执行一下图示的两个任务，后面就很顺利的使用`ssh`的功能了。
另外，如果是使用Docker安装的Gitea，因为容器和宿主机需要端口映射，所以为了使得`ssh`操作顺利执行，宿主机的默认`ssh`端口22，要修改成别的，Container的`ssh`端口映射成宿主机的22号端口。不同的是，下图中的两个任务，也能使用`ssh`功能了。
![gitea_ssh_problem](/img/posts/gitea_ssh_problem.png 'gitea_ssh_problem') ![gitea_ssh_problem](/img/posts/gitea_ssh_problem.png 'gitea_ssh_problem')