The openssl 3.0.0 using newer `PKCS#8` format.
But it's not compatitable with harbor core
So using tradictional format instead
Signed-off-by: Qian Deng <dengq@vmware.com>
Steps to reproduce:
Clone repo from master branch
Run: make install COMPILETAG=compile_golangimage
Wait until script will check that bzip2 is installed
Signed-off-by: YuriiPaneiko <yurapaneyko@gmail.com>
* Move request id to requestid middleware
* fix span pass to child ctx on orm
* fix typos
* remove unused code
* add operation name to Transaction
Signed-off-by: Qian Deng <dengq@vmware.com>
* use lib trace helper function
* add gracefull shutdown
* Add commens for new added exposed function
* Add licence on top of new created files
* Update trace library
* Update configs
* Add attribute and namespance in config
Signed-off-by: Qian Deng <dengq@vmware.com>
Logrotate is run with sudo as the syslog user by cron.hourly
The current working directory is `/root` which is inaccessible to the syslog
user so the logrotate command fails. Currently the following stderr is being
thrown away by the cron script:
```
error: cannot open current directory: Permission denied
```
Fixes#15468
Signed-off-by: Christopher Jenkins <christj@gmail.com>
Fixes#14932
Harbor recompiles the notary v0.6.1 with go 1.15 from v2.2.0, which introduces an break change that leads to notary key not found after migration.
[Root cause]
Notary v0.6.1 consumed an old version dvsekhvalnov/jose2, which is not compatible with go 1.15.
[References]
https://github.com/dvsekhvalnov/jose2go/issues/26https://github.com/golang/go/issues/41089
[Resolve]
To resolve this issue, we have to roll back go vesrion to v1.14 for notary v0.6.1 binary and keep it until upstream have a patch release to support go 1.15 or above.
[Break change]
If you pushed and signed image using Harbor v2.2.0 ~ v2.2.2 and created new repository key in notary, you will encouter the same issue after migrate to v2.2.3(or above) or v2.3.1(or above) because of the go version downgrade. We will have a FAQ to help you to resovle this particular scenario.
The influence path of the particular case:
Harbor v2.1.0(or lower) --> [v2.2.0 ~ v2.2.2] --> v2.2.3(or above)
Harbor v2.1.0(or lower) --> v2.3.0 --> v2.3.1(or above)
The non influence path of the paticular case:
Harbor v2.1.0(or lower) --> v2.2.3(or above)
Harbor v2.1.0(or lower) --> v2.3.1(or above)
[Fix in Version]
Harbor v2.2.3 or above
Harbor v2.3.1 or above
[Note]
If you're a heavy user of notary, avoid using v2.2.0, v2.2.1, v2.2.2 and v2.3.0, and use the fixed version for instead.
Signed-off-by: Wang Yan <wangyan@vmware.com>
Remove build base executable in Makefile by replacing it as an input parameter.
Add add more input parameters for controlling docker pull/push to make
build base process flexible for users.
Signed-off-by: danfengliu <danfengl@vmware.com>
Fixed#15034, as for postgres 13, the default shm size is 64MB, set to 1gb to avoid could not resize shared memory segment error.
Signed-off-by: Wang Yan <wangyan@vmware.com>
* add build arch parameter in Makefile
Add parameter BUILDARCH for make file. DB base builds pg96 for x86_64 only
Signed-off-by: Wang Yan <wangyan@vmware.com>
To ensure the upgrade execution idempotence, it needs to clean the $PGDATANEW on pg_upgrade failure.
Otherwise, the upgrade will skip the upgrade process from the second time launch as the exist of $PGDATANEW.
Signed-off-by: Wang Yan <wangyan@vmware.com>
1, use the pg source and photon spec to build postgres 9.6
2, install 9.6 on the photon 4.0
3, then leverage pg_upgrade to handle the pg major version migration
Signed-off-by: Wang Yan <wangyan@vmware.com>
