解决在Mac下iTerm2终端使用sz和rz命令报错问题

我们经常使用 sz/rz 命令进行文件的上传下载,非常方便。但是在 Mac 下面就不能直接使用了需要进行配置才能使用 昨天在给客户调试相关代码时,需要覆盖一些代码,使用 rz 进行上传时却报错了: rz waiting to receive.**B0100000023be50 使用 sz 下载也是报错:**B00000000000000 并且都会卡死终端一段时间 解决方案 解决的方案有点复杂,一点一点来看 安装 lrzsz 首先需要我们安装一下 lrzsz,使用命令进行安装:

配置 iTerm2 安装完成后我们需要在 iTerm2 中使用的话,还需要一些配置 进入到 /usr/local/bin 目录下,下载两个脚本文件

  下载好之后我们进行 iTerm2 的配置 点击 iTerm2 的设置界面 Perference -> Profiles -> Default -> Advanced -> Triggers 的 Edit Read more…

CentOS 安装Parallels Tools

CentOS 安装Parallels Tools 为了做到Mac和Linux之间共享文件夹,因此需要安装Parallels Tool, 具体安装步骤可以参考 install parallels tool for linux guest http://download.parallels.com/desktop/v4/docs/en/Parallels_Desktop_Users_Guide/22570.htm 具体步骤如下: 在Virtual Machine上点击Install Parallels Tools image 在Linux上我们会看不到/media/cdrom的内容,因此,需要手动地mkdir -p /media/cdrom, 然后再mount上去,mount的命令是mount -o exec /dev/cdrom /media/cdrom。 我们在/media/cdrom下看到install安装脚本了,运行su /media/cdrom/install就可以了,安装完按照提示重启centos后,就可以在/media/psf下看到对应的共享文件了,自己可以设置是可读还是可读写来着,默认是可写的。 参考: http://blog.hadoopspark.com/2013/12/centos-setup-under-parallels-desktop/ http://blog.csdn.net/mmical/article/details/39972573

TypeError: argument of type ‘PosixPath’ is not iterable解决办法

Django执行python manage.py migrate时报如下错误: File “/root/.python_env/.virtualenvs/venv/lib/python3.9/site-packages/django/db/backends/sqlite3/creation.py”, line 12, in is_in_memory_db return database_name == ‘:memory:’ or ‘mode=memory’ in database_name TypeError: argument of type ‘PosixPath’ is not iterable 这个问题应该是django2.0版本和python新版本不兼容导致的(我安装的是Django 2.2.13, Python 3.9.0) django2.0中,django/db/backends/sqlite3/creation.py的代码如下 而最新的django3.1此处的代码为: 如果不想升级django的话可以参照新版django修改即可。 不过要在文件前面导入Path,即: from pathlib import Path 所以改动如下:vim /root/.python_env/.virtualenvs/venv/lib/python3.9/site-packages/django/db/backends/sqlite3/creation.py  

 

解决Django:SQLite 3.8.3 or later is required

在我的CentOS系统上安装了django==2.2.8并创建了一个webApps项目,使用:

但是,当我使用以下命令初始化迁移所需模型时,发生了错误:

以上命令产生了如下的错误输出: django.core.exceptions.ImproperlyConfigured: SQLite 3.8.3 or later is required (found 3.7.17). django发现Python使用的sqlite版本过低,不满足要求。因此,我尝试升级自带的sqlite。使用sqlite3 –version查看了CentOS的Sqlite为3.7,我开始用yum remove sqlite移除了当前版本,并且编译安装高版本,参考比如:

  此时完成了sqlite 3.27.2的安装,但是系统默认认识3.7。因此链接新的路径:

  设置共享库路径:export LD_LIBRARY_PATH=”/usr/local/lib”:LD_LIBRARY_PATH并执行生效source ~/.bashrc 这个时候,使用sqlite3 –version时便会输出版本为3.27.2。可是当我再次执行python3 manage.py migrate时仍会报错,原来python使用的sqlite还是3.7:

  这个时候我就二丈摸不着头脑了,google了一下,解决方式包括未正确设定sqlite、尝试升级python版本、重新编译python等,重新编译太麻烦了吧,于是我发现了一个可以有效解决当前django必须使用sqlite3.8.3以上版本的问题。感谢,可以这样尝试: locate django将会输出大量包含django关键字的目录文件,可以看到django安装在哪些路径下,在我的系统上,需要找到/…/lib/python3.6/site-packages/django/db/backends/sqlite3/base.py这个脚本,django判断当前使用的sqlite版本的代码就在这里,找到以下代码块,注释掉那一行代码并更改:

  再次尝试django-admin startproject webApps便会执行成功 From: https://cloud.tencent.com/developer/article/1639633

build a docker-compose binary for aarch64/arm64

在uos(基于Debian)操作系统上, docker-compose也需要重新编译, 过程如下: 首先安装docker 获取软件包获取“Docker Compose-1.22.0”安装包。

  安装 进入docker-compose源文件目录。cd /usr/local/src/docker-compose-aarch64 配置Dockerfile。vi Dockerfile更改如下:由于是直接在uos机器上编译,所以不需要进行交叉编译,注释掉RUN [ “cross-build-start” ] pip install时老是timeout,在此增加timeout时间, 配置清华源 完整Dockerfile如下:

  安装docker-compose

  运行和验证   运行docker-compose容器

  拷贝执行文件:

 

搭建rsync服务器同步数据

最近在弄国产化操作系统适配,由于别人公司不让用VPN, 只能通过一个公网映射端口做ssh登录,而安装代码又是放在内网的其它服务器上, 代码调试很不方便,所以想到用rsync来从公网服务器上自动同步代码到内网服务器上 首先搭建rsync服务: 安装rsync:

在source服务器上运行命令(可以同时同步到两台内网服务器上)

  如果用cron来定时同步的话, 可以简单地配置ssh免密, 来通过ssh同步:

  注: 如果用rsync模块来同步的话, 可以来配置rsync服务器:

具体使用方法如下:

 

docker设置代理

docker pull某些镜像时速度特别慢,可以设置代理,设置方式是: 编辑/usr/lib/systemd/system/docker.service,加入:

 

git checkout 检出命令

检出命令(git checkout) 是git最常用的命令之一,同时也是个很危险的命令,因为这条命令会重写工作区: 用法一:git checkout [-q] [<commit>] [–] <paths>… 用法二:git checkout [<branch>] 用法三:git checkout [-m] [[-b|–orphan] <new_branch>] [<start_point>] 上面列出的第一种用法和第二种用法的区别在于,第一种用法在命令中包含路径<paths>.为了避免路径和引用(或者提交id)同名而发生冲突,可以在<paths>前面用两个连续的短线(减号作为分割) 第一种用法的<commit>是可选项,如果省略则相当于从暂存区进行检出(检出的默认值是暂存区)。 第一种用法(包含了路径<paths>的用法)不会改变HEAD头指针,主要是用于指定版本的文件覆盖工作区中对应的文件。如果省略<commit>,则会用暂存区的文件覆盖工作区的文件,否则用指定提交中的文件覆盖暂存区和工作区中对应的文件. 第二种用法则会改变HEAD头指针,主要用作切换到分支,如果省略<branch>则相当于对工作区进行状态检查。 第三种用法主要是创建和切换到新的分支(<new_branch>),新的分支从<start_point>指定的提交开始创建。新的分支和master分支没有什么实质的不同,都是在refs/heads命名空间下的引用。 具体示例: git checkout branch  检出branch分支,要完成上图的三个步骤,更新HEAD以指向branch分支,以及用branch指向的树更新暂存区和工作区 git checkout  汇总显示工作区,暂存区与HEAD的差异 git checkout HEAD 同上 git checkout — filename 用暂存区中filename文件来覆盖工作区中的filename文件。相当于git add filename的撤消,这个命令很危险,因为对于本地的修改会悄无声息的覆盖 git checkout — .  或写作 git checkout .  Read more…

python中的subprocess.Popen()使用

python中的subprocess.Popen()使用 从python2.4版本开始,可以用subprocess这个模块来产生子进程,并连接到子进程的标准输入/输出/错误中去,还可以得到子进程的返回值。 subprocess意在替代其他几个老的模块或者函数,比如:os.system os.spawn* os.popen* popen2.* commands.* 一、subprocess.Popen subprocess模块定义了一个类: Popen class subprocess.Popen( args, bufsize=0, executable=None, stdin=None, stdout=None, stderr=None, preexec_fn=None, close_fds=False, shell=False, cwd=None, env=None, universal_newlines=False, startupinfo=None, creationflags=0) 各参数含义如下: args: args参数。可以是一个字符串,可以是一个包含程序参数的列表。要执行的程序一般就是这个列表的第一项,或者是字符串本身。 subprocess.Popen([“cat”,”test.txt”]) subprocess.Popen(“cat test.txt”) 这两个之中,后者将不会工作。因为如果是一个字符串的话,必须是程序的路径才可以。(考虑unix的api函数exec,接受的是字符串 列表) 但是下面的可以工作 subprocess.Popen(“cat test.txt”, shell=True) 这是因为它相当于 subprocess.Popen([“/bin/sh”, “-c”, “cat test.txt”]) 在*nix下,当shell=False(默认)时,Popen使用os.execvp()来执行子程序。args一般要是一个【列表】。如果args是个字符串的 话,会被当做是可执行文件的路径,这样就不能传入任何参数了。 注意: shlex.split()可以被用于序列化复杂的命令参数,比如: >>> shlex.split(‘ls ps Read more…

docker和harbor启动失败解决

今天启动harbor时启动失败, 有几个问题, 记录一下: 重启docker,报错: msg=”Error starting daemon: layer does not exist” 解决:只能是清空docker数据目录了,实际上官方还提供了一个略微安全的删除脚本:

将该脚本保存到本地后运行sh fix.sh /data/docker,清空/data/docker目录,重启docker服务 docker-compose启动harbor, harbor-log启动失败 Changing password for root. sudo: unable to change expired password: Authentication token manipulation error sudo: Account or password is expired, reset your password and try again 解决: 参考:https://kb.vmware.com/s/article/79497 重新拉取镜像:docker pull goharbor/harbor-log:v1.10.3 修改配置文件,重启成功 Read more…