New Package Submission (Was: Self Introduction -- Derek Pressnall)
On Sun, Dec 27, 2020 at 11:32 PM Dan Čermák
wrote:
> The spec file is mostly good, I'd suggest a few changes though:
> - use macros instead of hardcoded paths, e.g. %_bindir instead of
> /usr/bin/
> - don't disable the debug package generation, Fedora packages must
> include debuginfo versions
> - replace make %{?_smp_mflags} with:
> %set_build_flags
> %make_build
> - mark LICENSE.txt as %license and not as %doc
> - there is no need to install the documentation under
> /usr/share/doc/snebu manually, you can just add the following into
> %files and rpmbuild will copy the files into the right place:
> %doc readme.md
> %doc snebu.adoc
> - I'd recommend to replace the %pre check for the snebu user with a
> systemd-sysusers config:
> https://fedoraproject.org/wiki/Changes/SystemdSysusers
>
> And one general issue not directly related to rpmbuild itself: does your
> Makefile honor the CFLAGS & LDFLAGS environment variables? Because if it
> does not, then all the compiler hardening flags that %set_build_flags
> inject will be just ignored.
I have made these changes, and updated to the latest upstream release
version 1.1.1. I have also ran through the following:
* Successful build under mock
* Success with Koji -- Task info:
https://koji.fedoraproject.org/koji/taskinfo?taskID=58581576
* All assets (spec file, srpm, upstream source) are published as
Github Release Assets, which are referenced in the ticket and the
.spec file.
* Have created a Bugzilla ticket: 1911565, and marked it as blocking
FE-NEEDSPONSOR
Anything else I've missed?
Since the package installs a binary that is owned by a non-root
utility account and SUID that user (for privilege management and
separation), I can prepare a security writeup on that mechanism
(essentially it compares the UID with the EUID -- if they don't match,
then it looks up the UID in an accounts permissions table to determine
which actions that user can perform).
Also if further information is needed on the encryption used, that is
at https://www.snebu.com/tarcrypt.html.
--Derek Pressnall
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction -- Derek Pressnall
On Sun, Dec 27, 2020 at 11:32 PM Dan Čermák
wrote:
> I have not really looked into the source code, so forgive me if that is
> obvious, but why is the snebu executable setuid?
This is for
1) Privilege separation -- application owns the files in the target
repository (/var/lib/snebu); you will typically be running the backup
front-end (snebu-client) as root so it can read everything, but the
snebu binary that gets called doesn't need root access.
2) Permissions model -- You can set up service user accounts for each
host (client) that is submitting backups (so they can see only their
own backup, or they can submit backups but not expire old backups
[expiration permissions would be assigned to a separate maintenance
user for further protection], etc.). This protects you in the case of
a client compromise so an attacker can't delete all your backups.
> The spec file is mostly good, I'd suggest a few changes though:
> - use macros instead of hardcoded paths, e.g. %_bindir instead of
> /usr/bin/
> - don't disable the debug package generation, Fedora packages must
> include debuginfo versions
> - replace make %{?_smp_mflags} with:
> %set_build_flags
> %make_build
> - mark LICENSE.txt as %license and not as %doc
> - there is no need to install the documentation under
> /usr/share/doc/snebu manually, you can just add the following into
> %files and rpmbuild will copy the files into the right place:
> %doc readme.md
> %doc snebu.adoc
OK, will do.
> - I'd recommend to replace the %pre check for the snebu user with a
> systemd-sysusers config:
> https://fedoraproject.org/wiki/Changes/SystemdSysusers
I tried this initially but couldn't get it to work inside a VM booted
from a Fedora Live image. I followed the instructions here:
https://docs.fedoraproject.org/en-US/packaging-guidelines/UsersAndGroups/
and created the appropriate file snebu.sysusers, but the pre install
with this line in it:
%sysusers_create_compat %{SOURCE1}
I'll test again with a full install in the VM instead of the live
install and see if that makes a difference.
Also, if I want the spec file to be compatible with older RHEL
releases (that predate the %sysusers_create_compat macro), should that
just be a separate spec for each version? or should I wrap the above
in a conditional (test for the macro and fallback to manual account
creation)?
> And one general issue not directly related to rpmbuild itself: does your
> Makefile honor the CFLAGS & LDFLAGS environment variables? Because if it
> does not, then all the compiler hardening flags that %set_build_flags
> inject will be just ignored.
I'll add this in. Also the make file needed the $(CC) variable instead of gcc.
Meanwhile, a couple additional questions. Right now I have a template
of the spec file in the project's Git repo. Should the spec file be
in its own repo (or possibly an orphaned branch of this repo)? That
way all packaging-specific items can be versioned separately from the
app itself.
Secondly, I'll put the above Makefile modifications in shortly, but it
may be a bit before the next posted release of Snebu. So for the
purpose of the RPM, should I put them in as patches (that are owned by
the rpm) until the next Snebu release comes out?
Thanks.
--Derek Pressnall
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Self Introduction / Contributing a package to Fedora
Why? Rsnapshot and AMANDA are already available, stable, and quite robust. They seem to cover just the niches you're aiming at, and the performance and security ramifications have already been worked out. Plus, neither requires an SQL database, which makes them much more robust. It's nothing personal or criticizing your code. I just wind up cleaning up after a lot of projects that reinvent the wheel. Backup systems are a popular such target. Good questions. Amanda and Bacula both are good full-featured backup tools, however they take a bit to set up and get working. I was previously using something similar to Rsnapshot, but wanted compression, and better file-level deduplication (Rsnapshot will de-duplicate files that are the same between backup sets, but not files that are the same from multiple hosts, or different copies of files on the same host). And the dedup method it uses (hard links) can make for a very large set of files to analyse on the backup media (in my case, backing up 20 odd hosts, keeping daily/weekly/monthly backups ended up with 600 total backups on the storage unit, and about 300 million files. Which made for keeping an rsync'd copy of the backup drive a bit tedious (not to mention running a find command to get stats about the files, such as the largest ones or which were unique, to improve the include/exclude list). This is where the SQL database comes into play -- I can easily get the top space-consuming unique files/directories, etc. BTW, only the file listings / metadata are included in the DB -- the contents are stored as lzop compressed files in the filesystem. And since the SHA1 hash is used as the file name, you get full file-level deduplication across multiple hosts for free. Other systems I looked at were Backuppc, which seemed like it was a bit more complicated (both setup and internal workings -- couldn't find how to execute pre/post backup scripts for live DB backups, etc), Obnam (stores backups in an internal binary format, has issues with a daily/weekly/monthly retention schedule), and a few others that were still based on the rsync/hardlinks method. BTW, here's a list of what my main design goals were, compared to other tools. * Keep the backend data format as transparent as possible (files are stored in lzop-compatible format, and the data catalog is in an sqlite database). Didn't want the data to be in a big blob like some of the non-rsync based Linux backup tools. * Use the database for identifying duplication, instead of hard links in the filesystem (when using an rsync backup with hard links, I couldn't in turn rsync the entire backup drive to another volume in any reasonable timeframe). * Use tools that are already on the clients so there is no agent to install (find, tar). * Advanced features, such as preserving selinux attributes, ACLs, and handle sparse files properly. * Have the metadata in a database that can be queried with SQL syntax for reporting and diagnostic purposes. I still owe documentation on the DB schema layout though. * Easy to get up and running (install, configure a couple lines to point to the backup media and run), while retaining flexibility in setting up a client/server installation. And thank you for your feedback, if there is anything that the above doesn't cover let me know (or if you think there needs to be more documentation, additional features [without adding too much complexity]). If the SQlite DB is a concern, there is also an import/export function to dump the metadata in a tab-delimited text file. Summary: Snebu fills a gap between simple, and more full-featured flexible systems, without being overly complex or opaque. -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction / Contributing a package to Fedora
On Tue, Jul 29, 2014 at 1:30 AM, Matthias Runge mru...@matthias-runge.de
wrote:
A few remarks about your spec given at [2]:
- Source0 should be a valid URL (if possible)
- in files section, you should use %{_bindir} instead of /usr/bin
- the same applies to your install section
- and of course your changelog must contain entries
- insert real version numbers and release numbers to Version and Release
Thanks for your input, this really helps. I will fix these errors, compare
against some other recent SRPMs, and get it in shape before requesting
formal review. Just a couple more quick questions:
For the Source0 URL, since this project is hosted on Github, the URL that
leads to the tar.gz file doesn't contain the tar file name (it is
https://github.com/derekp7/snebu/tarball/master;, which ends up creating
the tar.gz file name on the fly through HTTP header / javascript magic). I
will address this by attaching an exported copy of the tar.gz file as a
binary asset to the Github progject release.
Also, in the spec file, the release is 1%{?dist} so that is uses the dist
macro to fill in automatically. But I'd like for the SRPM file to be
release agnostic (so I don't have to host one for each release of Fedora).
If I rename the .src.rpm file to not include fc19, then rpmlint
complains. Is there a proper way to build the SRPM so that the binary RPMS
built from it use the %{?dist} macro, but the SRPM is release agnostic?
Or should I just one SRPM for the most current Fedora release?
Thanks.
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Self Introduction / Contributing a package to Fedora
I have a question about contributing a package to Fedora. Is it common for the author of an open source package to act as package maintainer? Or is it better to have someone else be the package maintainer (who is more experienced with the Fedora build processes)? I'm the author of a backup utility which fills a niche between tools based on rsync, and the heavy-weight full featured backup tools, which I think would be a good fit for a typical Fedora user. I already have an SRPM available on the Github project site (www.snebu.com), but it may need a bit more work to get it in line with the Fedora build system. I've also been reading through the package maintainer guidelines, and am willing to go through the process too, if needed. I have already created my Fedora and Bugzilla accounts, and will spin up Koji this weekend to play with. Thanks, --Derek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Self Introduction / Contributing a package to Fedora
On Mon, Jul 28, 2014 at 7:57 PM, Stephen Gallagher sgall...@redhat.com wrote: The Fedora packaging process can be a bit tricky the first time around; I'd recommend locating a member of the Fedora Sponsors who is interested in helping you with your first package and showing you the ropes. Ok, where do I find a Sponsor? on this list, or is there another one? Or is that the whole part where I have to submit the package, open up a bug report, and reference that here? (I think that's what I got out of the docs last time I went through it). Thanks, I'm looking forward to helping where I can -- I've got some somewhat decent C programming chops (going back about 25 years, although always on the side and personal projects -- professionally I'm a systems engineer). --Derek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Re: Submitting new package
Thanks. I've got the license info (GPLv3) pushed to the git repository, but need to tag a new version for it to show up on the download page (probably tonight once I get a couple more front-end scripts in the repo). On Wed, Feb 20, 2013 at 2:34 PM, Miro Hrončok mhron...@redhat.com wrote: Hi. Not answering your questions, but I would strongly recommend to add a LICENSE or COPYING file with the license of your app. -- Miro Hrončok -- Phone: +420777974800 Jabber: m...@hroncok.cz -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Submitting new package
Hello, I'm looking at submitting my first package to Fedora, for a backup system I recently contributed as open source. I've read through most of the packaging guidelines (and have been doing RPM packages in a corporate environment for a few years), but have a few Fedora-specific questions. Is this the proper list to ask? Thanks. --Derek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Submitting new package
On Tue, Feb 19, 2013 at 3:01 PM, Paul Wouters pwout...@redhat.com wrote: On Tue, 19 Feb 2013, Derek Pressnall wrote: Is this the proper list to ask? Thanks. Yes it is! Paul Cool. First off, I'd like for someone to review my project in general terms, while I'm working on the RPM, to validate that it would be a positive contribution to Fedora. My project, called Snebu (simple network backup utility), is currently hosted on github (can get to it via www.snebu.com, github page is github.com/derekp7/snebu). The target audience is sysadmins who are currently using rsync/snapshot style backups, and need to go to the next level up without having to maintain one of the heaver-weight tools such as Bacula or Amanda. Second question: When I create the package, I should include a default configuration file. One of the configuration options is the location of your backup media (currently only disk-based targets are supported). This means specifying a mount point, such as /var/backups. Which directory would be an appropriate default for FHS / Fedora compliance? I was thinking maybe /media/backup. Finally, even though the main program binary is intended to be used directly, it is easier to have a client script that sets several default command line options. This client script currently exists only in the documentation (as it is a template that is intended to be customized), but was thinking of either placing it under /usr/share/pkgname-version/templates, or making an improved / general purpose client script (config file driven, etc), and having it a first-class component of the package. If that is the case, even though it would still be just a simple shell script, should I package the client script as a separate package? That way it can be installed easily on a number of clients, and have the server component only installed where your backup media is located. Thanks. Oh, btw, one of the items on my task list is to give the documentation another rev, currently it is just a long readme file. Thanks, --Derek -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
