Hi
This is a continuation of the thread here:
IPFire Community Gathering some info from Firewall Logs is hard
The purpose of this thread is to discuss the hypothesis that ipFire, as a product, could be significantly improved by improving usability.
I will only briefly point out that the IPFire dev team is very small and working towards next major release, version 3.
From what I have seen in other posts, the version 2 branch is not the target for any bigger improvements so we may have to wait and see what comes with version 3.
Hi
It is good that this issue has been fixed so quickly.
As a more general comment, ipFire is weak in the area of helping a non-tech user look for threats and issues. Advice to trawl through cryptic logs from the CLI is evidence of that.
An example, something as simple and fundamental as finding out who is connected behind the firewall is not a feature of ipFire. This requires the installation of an add-on âWho is onlineâ. I only discovered the existence of this add-on via this forum. It is a good add-on, so good I believe it should be part of the default ipFire.
1 Like
Having said that, and I do not disagree, I come from using both Zyxel FW appliance, OPNSense and Mikrotik. Setting up the basic network and enabling the firewall was, to me, a lot easier in IPFire.
Zyxel was just hard to get how to do things, OPNSense the same, and trying to setup Mikrotik as a firewall using RouterOS was a complete nightmare to me: Building Your First Firewall - RouterOS - MikroTik Documentation .
Admittedly I can not really compare which option is safest or more secure, but I needed something I can understand and configure in a reasonably easy interface and so far I have come a lot further with IPFire than with anything else.
Also, considering costs, while OPNSense and IPFire can be installed on your own hardware, I spent maybe 200⏠on my server, going Mikrotik and Zyxel demands the purchase of their hardware, which was about 600⏠for a router and a switch. Sure I could have used any switch, but not any router, and I actually believe in using the same brand for that kind of network equipment, so I have been re using my original Ubiquiti EdgeMax (not Unifi) devices and are very happy with that.
In fact, I have been messing with different solutions for maybe 5-6 years before landing with IPFire on a custom server. I can only hope the team is able to continue the development and improve even more on the interfaceâŚ
2 Likes
Concerning the configuration it has to been said, that the situation is a bit tricky.
The development team is ( hopefully 
) keen with networking. Therefore it is a bit difficult to decide which features should be integrated.
In case of logging most advanced users use the CLI; it is much easier to search, compare, analyse just the system files ( if you have the knownledge ).
Therefore deficiencies in the WUI are not really detected by users able to correct them, the devs.
It is necessary, that âstandard usersâ of IPFire bring up these problems. The quickest way to do this, is the Bugzilla site. Devs able to do the corrections are notified about those posts very certainly ( another channel is the development mailing list ).
EDIT: added a link to our bugzilla page to make things clearer.
3 Likes
Hi
I generally skim through emails about ipFire posts, so it may be no surprise that this is the first time I became aware of the Bugzilla channel to the Devs for ipFire.
The reason the ipFire WUI exists is to protect users from the CLI. If users could live in the CLI, they wouldnât need ipFire. Usability should be a very high priority for the developers.
Telling users to go to the CLI indicates a deficiency in the usability of WUI. I doubt most users of ipFire want to, or can, use the CLI.
Telling users to read documentation is reasonable for complex tasks. Simple things should be simple and obvious to do. Simple things should not require reaching into the documentation.
I donât have the skills to directly contribute to development of ipFire. In my day job, I manage developers. I suspect most users of ipFire are also unable to directly contribute to development. The best way I can contribute is to provide user feedback.
I have just had a look at the Bugzilla website. It seems that using Bugzilla requires me to install and learn a new (to me) application. This might be great for the Devs. From a user perspective, this really awful.
I am using ipFire because I like it. It is also the reason I am providing this and other user feedback. The aim being to improve the user experience. Improving the user experience will increase the appeal of ipFire and make it more popular.
1 Like
Yes, this is true. With limited resources (few volunteers, everyone working day jobs, and limited funding) it makes it very difficult to focus on things that are not security related. If you manage developers, maybe they can assist improving the WebGUI? It would be a nice skunk-works project!
No install needed. It is just a website. Why do you believe an install is needed?
1 Like
Hi
I went to the Bugzilla website and it says âThe software solution âŚâ plus a download page. I stopped there.
If the ipFire project has an accessible Bugzilla page already, that would be great. I canât find a link to it on the ipFire website. If I needed a separate log-on to this forum, that wouldnât be so good.
Software development is always resource constrained. I appreciate the ipFire developers are a scarce resource. It then become an issue of setting priorities. Specifically for the WUI, one of the ways would be to create a user wish list which basically includes column for features, user votes and developer effort (cost). Features with high votes, and low cost will float to the top.
Hi all,
@dazz as @jon posted already above the bugzilla link which you may have overseen , here again, you can find IPFire´s bugzilla here â https://bugzilla.ipfire.org , there is no need to download your own .
Also in here â wiki.ipfire.org - Bugzilla are further information about your needed account to write to bugzilla which you already accomplished with the community account (same credentials).
And in here as a general info resource â https://wiki.ipfire.org you should find all the other links above included.
Best,
Erik
3 Likes
OK thanks for the info.
I had a quick scan through Bugzilla and it looks good for developers.
I found the bug reporting section, but I did not find a feature request section.
If I want to submit a feature request that is not a bug, where and how would I do that?
For non-developer users, elements of the Bugzilla bug reporting page are user hostile. To be specific:
No âUnknownâ There is no component label if the reporter doesnât know what a component is, what it does, or what it is called.
No WUI A user is most likely to report a bug with the WUI because that is what they will interact with. After a scan through the components, I canât find one that would apply to the WUI.
- - - I get that this is the catch all category, but it would be better if the note was modified to say something like âIf reporting a bug in the Web User Interface (WUI) of ipFire, or the component is not known, please use this category. If submitting a new feature request that is not a bug, please follow this link : www.ipFire.I_want_to_ask_for_a_new_feature.comâ
wiki.ipFire Feature Road Map I did a search for âfeature requestâ and nothing useful for a user was returned.
This post contains feature requests. This forum is probably the wrong place to put it. Same with Bugzilla. There are no bugs here. If there is somewhere to submit feature requests, I havenât found it, and I have searched.
That is the component to use for any IPFire-2.x bug, the specified components are for use with IPFire-3.x.
See the wiki entry.
https://wiki.ipfire.org/devel/bugzilla/workflow#assigned
1 Like
@dazz
This is a can of worms. We started this thread with identifying a better method to present firewall data, and you dragged it away to a CLI vs UI discussion.
It is not entirely unrelated, of course, but you should have made that in a new thread, trying to keep this more on topic and related to the readability of logs and what improvements can be made there.
I do not know if continuing with this derived discussion - which in itself is very interesting, but you have an approach that is not entirely correct - or asking for moderators to step in and clean out the thread, moving it to another new thread where that discussion can continue. I think the latter is appropriate.
Anyone can create a new thread about CLI vs UI and I shall be happy to take part, but I will not continue that discussion in this thread unless okayed by Mods.
1 Like
Hi
@sec-con Agreed. I didnât intend this discussion to get to where it has.
I have started a new thread here:
Improving Usability ?
@bonnietwin I looked up the link you referenced and it includes the statement " for IPFire 3 choose one of listed components or --- if none of those components fit the situation" If it the ipFire team is tracking who views that page, I suspect they would be best described as developers, but not just users.
That is correct but just before that statement it says
for now and for IPFire 2.x always choose
---at the top of the list
So IPFire-2.x should always have ---
That is in the developer section but it is open to more than just developers. I read it and I raise bugs and I fix some bugs as well.
I am definitely not a software developer. I do software stuff for fun. My career was always in semiconductor engineering and never in software development.
That has not prevented me deciding to not only use IPFire but to try and help in its growth, where my skills have allowed and those skills have expanded as I have been involved in this work.
Anyone who wants to take part or support is able to and is welcomed. You never stop learning, no matter how old you are.
There is no need to search through the logs on the CLI.
You can access the logs via the WUI as described in this wiki page
https://wiki.ipfire.org/configuration/logs
If you want to do more filtering or sorting etc then this can be done via other external tools, such as Browser, Excel etc, by using the Export command on the WUI log page to make all the log data for that WUI page available in a text format.
1 Like
My statement about CLI âcrawlingâ tries to describe the problem of finding issues in the WUI.
Users/devs with a certain level of ability to read/write/correct the source code driving the IPFire system tend to use CLI for deeper log analysis. Therefore they seldomly see problems in usability.
It is the part of IPFire users, which use mainly/only the WUI for configuration and analsysis, to report those cases. Just my opinion.
Few years ago a customer would like to have a âcomplete yet fast and easy explanation of internetâ.
My answer was quite harsh âI can provide a complete, yet fast answer however youâre lacking of all the background knowledge to understand itâ. He was dissatisfied, so I tried to get a bit more close to his knowledge. Heâs an electrician.
âItâs like explaining to a lady whoâs running a 3000w heater on 0,5 mm2 extension why it melt without her knowing ohm and cable section. You can tell her itâs not a good idea, but you donât know if you donât explain why if sheâll do it againâ.
Now.
Ipfire is built on top of Linux and other GPL softwares, some old, some newer. It chews network hardware, network software, firewalling, scripting, network application (like a proxy is).
So⌠any experience on these topics
- Linux administration
- Linux filesystem standards
- Ethernet
- Wireless Ethernet
- ETSI vs FCC radio regulations
- vLAN
- TCP/IP (also with routing)
- Application server
- Web Management
- Network administration
- File Sharing administration
- Cyphers
- Security news
- shell friendliness
- hardware info lookup and evaluation
- CPU and performance comparison
can help a lot while toying and experimenting not only on IpFire, but also on other firewall distros.
Which is sad to say⌠but are falling, stumbilng and kept behind.
10 years ago at least 8-9 projects were nice enough to give a try.
Now most of Linux-based firewalls donât survive to kernel more recent than 4.x, are IPv6 support lacking, do not have enough features or are simply⌠too old and without important security updates.
On development side: not enough resources.
On adopter side: not nice, fast and simple enough.
So.
Robustness and security are keypoints for firewall-UTM(ish) distros. But adopters grow (and consider support) if itâs fast enough install, deploy, setup and fix issues (if they donât appear, better so).
Itâs the usual three-requirements cross-section
Adding insult to injury, commercial (and closed source, BSD-based) products are gaining traction, sometimes without technical merit but with a lot of margin-pyramid logic. Higher margins and revenues, more resellers will go that route.
Sorry,too much sidetracking.
Three fast hints:
- improve solidity of the upgrade path.
I had to quit IPFire installation for Endian Firewall on ESX 6.5 guest 6 years ago because after a Core update the installation kernel-panicked. I donât exacly blame IPfire, probabile several things needed to be verified better by me or ESX had to be patched a little more. However⌠Endian was mostly ready, a fast shutdown/power on-and-reconfigure was faster than âpost crash analysisâ. - accept the fact that more than sometimes, core updates can screw up, and sometimes a lot. I was âgently pushed outâ for a month because the DNSSEC messly adoption created⌠more than hundreds of victims
- GUI usability and understand itâs a⌠feature, not a hassle. It will ease a lot questions
- some howtos on how get to more useful info while the GUI is not available⌠might help to reduce the âwhat the heck happenedâ topics for more âsomething went wrong, this is what I foundâ. Or at least⌠might be an howto/wiki article to link when someone starts crying too loud.
I donât know how old is IPFire3 as âproject announcementâ. Iâd love to see a tenth of the budget of Star CItizen provided to that. However⌠Preproduction dated 2010, Kickstarter campaign dated 2012.
IDK⌠maybe itâs the time?
2 Likes
Well, that is true for many software developers, not just firewalls. You give a few relevant pointers, if not most, but you do only somewhat address the usability.
Letâs face it. CLI is powerful. For anyone willing and able to get through itâs paces, you can run this firewall - and many other apps - with CLI and text based configurations only. I learned that the hard way with Mikrotik, everything was around code and conf. Yes, RouterOS has come a long way, I do not know itâs status today, I used it three years ago, but I would never call it userfriendly. I always had the impression they mapped the CLI in to an interface without any real pedagogical insights. OPNSense is not very different, but it looks âshinierâ.
I took a swing with my buddy ChatGPT and assuming I asked the right question here is a candidate list of pros and cons.
ChatGPT
When comparing the Command Line Interface (CLI) and Graphical User Interface (GUI), there are various pros and cons associated with each. Hereâs a list to provide a more detailed argument:
Command Line Interface (CLI):
Pros:
- Efficiency:
- Pro: CLI is often faster for experienced users who are comfortable with commands. Keyboard input can be quicker than navigating through graphical menus.
- Resource Efficiency:
- Pro: CLI typically consumes fewer system resources compared to GUI, making it suitable for resource-constrained environments.
- Scripting and Automation:
- Pro: CLI allows for easy scripting and automation of repetitive tasks, enhancing productivity and consistency.
- Remote Management:
- Pro: CLI is well-suited for remote server management, as it can be accessed through secure shell (SSH) without the need for a graphical interface.
- Scripted Reproducibility:
- Pro: CLI commands can be easily documented and shared, ensuring reproducibility of actions across different systems.
Cons:
- Learning Curve:
- Con: CLI has a steeper learning curve, especially for users who are not familiar with command-based interactions.
- Limited Discoverability:
- Con: Commands and options are not always discoverable, requiring users to memorize or refer to documentation.
- Non-Intuitive for Novices:
- Con: Novice users may find CLI less intuitive, as it relies on text-based commands rather than graphical representations.
Graphical User Interface (GUI):
Pros:
- User-Friendly:
- Pro: GUIs are generally more user-friendly, making them accessible to a broader audience, including non-technical users.
- Visual Representation:
- Pro: GUI provides a visual representation of actions, making it easier for users to understand and interact with software.
- WYSIWYG (What You See Is What You Get):
- Pro: GUI often follows a WYSIWYG approach, allowing users to see the immediate impact of their actions.
- Reduced Learning Curve:
- Pro: GUIs typically have a lower learning curve, as users can navigate through menus and options without memorizing commands.
- Rich Multimedia Support:
- Pro: GUIs support rich multimedia elements, which is beneficial for applications where visual content is crucial.
Cons:
- Resource Intensive:
- Con: GUIs can be more resource-intensive than CLIs, potentially slowing down performance, especially on older or less powerful hardware.
- Limited Automation:
- Con: While GUIs have improved in automation features, they may not be as scriptable or automatable as CLIs for certain tasks.
- Not Ideal for Remote Systems:
- Con: GUIs may not be suitable for remote system management, as they often require a direct graphical connection.
- Dependence on Mouse Input:
- Con: GUIs heavily rely on mouse input, which might be less efficient than keyboard commands in some scenarios.
It takes time and effort to code an interface for what was originally a text based app. I know very little of the code behind IPFire, but I have dabbled enough in web interfaces and similar tech to understand that an UI is often a hindrance for a quick and efficient function. There are so many parameters to consider. So much testing and so many things that can go wrong.
So from an application that works out of the box using CLI - a simplified statement - one has to make it user friendly for the people who do not care to learn CLI - also a simplified statement - and why should we (the developer) since those guys wonât really know what to look for anyways to know that they are safe?
The latter is kinda true for me⌠sorry⌠but I need to be honest, I ponder how safe I am and how I see that, yet find no simple answer. There are many web services that can do a port scan and similar tests of my network and I pass them all, an old favorite is https://www.grc.com/ and the services one can use there.
I hope I did not get too many wires crossed in above text.
EoL
Hi
I am taking the opportunity to explain a few things below.
** The definition of a âUserâ**
My working definition of a user is a 12 year old with particular interest in the application. I could write a long explanation for defining why 12years age, but I will keep it short and simple.
Good political speech writers aim for their work to be easily understood by a 12 year old. Both Apple and Microsoft are immensely popular products. They do everything they can to shield the user from technical stuff. Most Win/Mac users wouldnât know what the CLI is, or why anyone would use it. Win/Mac are easily operated by a 12 year old.
When I look at developers work intended to be exposed to Users, I ask myself, how would a 12 year old act, think and respond to what they see.
Why donât I contribute to writing code
I learned to code BASIC on a TRS80 and have continued to code unprofessionally in a variety of languages. I have never sat in front of a CLI while in paid employment. The largest software project I directed, for installation at a bank call centre, had 22GB of compiled code.
I donât get hired to write code. I get hired to manage and direct others that are much better at writing code than I. I play to my strengths.
The Recipe for Success
I have been managing and directing major projects for a long time, many of them I have taken on as project rescues. There are more than a few things needed to make a project successful, but the universal ingredient is to identify and eliminate the points of failure.
It doesnât matter how many good things promote the success of a project, it only takes one fatal flaw to kill a project. There are many examples in the public domain. The classic example is the VHS vs Betamax battle. The technically inferior product won.
So I always seek to identify and eliminate the negatives in order to achieve a positive outcome. For anyone that doesnât know that, everything I say just looks negative, negative and more negative.
Why am I doing this
I have looked at other products after ipCop died, and came back to ipFire. I am doing this because I like ipFire.
Scarce Resources
Many projects, especially software, run with not-enough-resources. It becomes really important to prioritize work. This includes shedding non-essential work to develop non-core features.
The most successful project I ran was in parallel with 13 other countries all striving to implement the same project first. All I had in my team was a new recruit and an old guy waiting for retirement. I was competing against project teams with vast resources and higher priority. My project came ahead of all of the others. Scarcity of resources may be an excuse, but not a reason, for sub-performance.
What to do??
When I look as this page: ipFire Website : page 1 I see that âSecurity is the highest priority in IPFire.â That makes perfect sense.
Above that the page states "Its ease of use⌠" as a key feature. So if security is the highest priority, then I would expect âease of useâ to be 2nd priority, or close to it. As such it would be reasonable to allocate at least 10% of scarce developer resources to the WUI. If that is already happening, then I havenât observed the results.
If 10%+ of resources were to be expended on the WUI, what should be done?
Make changes to describe what things, do, not what the are. Examples include:
Chaning âPACFIREâ to âUPDATES & ADDONSâ. No one should care, or need to know, that PACKFIRE is running.
Looking at the available list of addons, the items are given cryptic names that no user is likely to understand. The only addon I have installed is called âwio-1,3,2-17â. The Wiki has a good summary of addonâs ipFire Addons that should be in the WUI. Easy tasks should be easy to do without the need to explore documentation.
Drop 20% of Addons
If security is the priority and resources are scarce, then addons reduce security and expend resources. Installing addonâs increases code, the risk of bugs and security flaws. I would look at shedding the least used addons a rate of 5% per year for 4 years.
Reducing effort to support little-used addons will free-up scarce developer resources for higher priority work.
Capture User Requirements
Bugzilla is used to report bugs, but there is no process to capture user requests for features or modifications, specifically to the WUI. A capture process would help prioritize scarce resources to meet the needs of users. Any such process needs to be transparent and easy to use. This would include allowing users to vote up feature requests by others that they support. I think most of the infrastructure is already included in the Wiki for a simple honesty box system open to registered users.
Summary
In summary, the WUI is both a strength and weakness of ipFire. Most of it is good, parts of it are not.
The changes I have proposed are small scale that should have a close to net-zero effect on resource demand.
The addition of a simple user requirements process based on the existing wiki will help focus scarce resources on what is important to users. That can only make ipFire more appealing to a wider range of users.
5 Likes
I do not agree with your definition of user, not in this context.
In regards to shielding form CLI, well I donât agree either, since the expansion of PowerShell and the release of the new Terminal and âcollaborationâ with Linux via WSL, and many other things⌠I am an UI guy, but I have never before been forced in to so much CLI as the latter 5 years. Not since I edited my W95 boot floppies.
Other than that, you raise some interesting additional points. Seems we have been âin the businessâ for a similar time span, yet draw some rather different conclusions.
I agree with your arguments.
Some thoughts of mine ( an âoldâ systems programmer with a background in informatics ).
- To reach the usability of Windows or even a car, there has to be a huge community of humans using the system and reporting their experience. I doubt, we have reach that yet.
- Another approach to achieve this, could be a team of developers knowing exactly what is needed. This is utopian.
- The process of feature request should not be integrated into the wiki. The wiki is the documentation of IPFire ( hopefully ). IMO features should be discussed in the community. To be successful, there must be a direct connections to the core devs; either by obligation ( not really possible ) or by means of the moderators, which transfer those ideas to the development mail list ( happens sometimes yet ).
- Development of a WUI and of an OS are two different parts of software engineering. Maybe there are some users of IPFire with knowledge in the first topic, which could join the development team. This demands moderation between the two branches, also.
- Without at least basic knowledge of networks systems you cannot setup and administer a system like IPFire. This includes basic knowledge of the underlying OS ( the real system, not just the graphical interface! ), this includes the CLI. This is true if development canât set standards for the HW level and the BSP as Microsoft does.
3 Likes