Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Debian/Ubuntu support #61

Open
Vincent43 opened this issue Jul 24, 2020 · 6 comments
Open

Debian/Ubuntu support #61

Vincent43 opened this issue Jul 24, 2020 · 6 comments

Comments

@Vincent43
Copy link
Collaborator

Vincent43 commented Jul 24, 2020

For support Debian/Ubuntu preparation of special version of initramfs script is needed. Also adding deb build recipes in debian subdirectory.

@Vincent43 Vincent43 changed the title Add initramfs script for debian and support deb packaging Debian/Ubuntu support Jul 24, 2020
@agherzan
Copy link
Owner

Do we have any debian/ubuntu users?

@Vincent43
Copy link
Collaborator Author

Our runtime scripts work just fine on debian but until we add initramfs script it's not possible to unlock device on boot which limits usefulness of this project for potential users (note that initramfs script for debian can be much simpler than for Arch as they support keyscript option in crypttab). As yubikey-luks is practically abandoned I think we can provide much better alternative here with not much effort.

@agherzan
Copy link
Owner

I see. That makes sense indeed.

@crispy-landslide
Copy link

@Vincent43 I have a working implementation for Debian/Ubuntu support. Before I clean up the code and do more testing, I wanted to get a second opinion on the file structure.

My implementation would change the file structure of the repository. I thought it would be best to have the arch build files in their own directory, the debian build files in their own directory, and then the shared files in the src directory.

Old file structure:

yubikey-full-disk-encryption
|- CONTRIBUTING.md
|- LICENSE
|- Makefile
|- PKGBUILD
|- README.md
|- testrun.sh
|- src/
|   |- initramfs-suspend
|   |- ykfde.conf
|   |- ykfde-enroll
|   |- ykfde-format
|   |- ykfde-open
|   |- ykfde-suspend
|   |- ykfde-suspend.service
|   |- hooks/
|   |   |- ykfde
|   |- install/
|   |   |- ykfde

New file structure:

yubikey-full-disk-encryption
|- CONTRIBUTING.md
|- LICENSE
|- README.md
|- arch/
|   |- Makefile
|   |- PKGBUILD
|- debian/
|   |- key-script
|   |- Makefile
|   |- debian/
|   |    |- changelog
|   |    |- compat
|   |    |- control
|   |    |- copyright
|   |    |- rules
|   |    |- ykfde.postinst
|- src/
|   |- initramfs-suspend
|   |- ykfde.conf
|   |- ykfde-enroll
|   |- ykfde-format
|   |- ykfde-open
|   |- ykfde-suspend
|   |- ykfde-suspend.service
|   |- testrun.sh
|   |- hooks/
|   |   |- ykfde
|   |   |- ykfde-deb
|   |- install/
|   |   |- ykfde

@Vincent43
Copy link
Collaborator Author

Vincent43 commented Jan 12, 2022

@crispy-landslide thx for working on this!

Separating Archlinux/Debian files is good idea. I think we should use archlinux instead of arch for better clarity (arch often stands for hardware architecture).

Also I think we need this separation for both packaging files and actual sources. Each file related only to creating distro packages should be placed in packaging/<distro_name> path while source files useful only in specific distro should be placed in src/<distro_name>.

Considering above I would make following changes:

arch/ -> packaging/archlinux
debian/ - > packaging/debian
debian/key-script -> src/debian/key-script
src/hooks/ykfde -> src/archlinux/hooks/ykfde
src/hooks/ykfde-deb -> src/debian/hooks/ykfde
src/install/ykfde -> src/archlinux/install/ykfde

Something like that. I may miss something but you can see the general logic.

EDIT: all suspend stuff should go to src/archlinux

@LaszloGombos
Copy link

Debian packages dracut and dracut usage on Debian based distribution is increasing. I think recommending dracut for ykfde is a reasonable option.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants