Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > You now want to replace of the components, but since it's very dependent > on the rest of the system, you are having a hard time finding a > replacement. It's even difficult to describe the requirements, because > it's something really unusual. > > So: have you considering replacing the whole system? > > Sure, in the short term it will be costly. > > It'll be difficult, and cause disruptions. The users will have to be > trained in the new system, productivity will decrease a little until > they get proficient in it, there might be the need for some downtime, etc. > > So I totally understand that what I'm proposing is not something easy to > ask. But given that the difficulty you are having in replacing this one > component will likely be repeated when some other part needs to be > changed, I do not think it's entirely unreasonable that this option is > studied. I completely understand your point of view and I agree that the decision to replace the entire system is a complex matter. However, it is not within the scope of our project team. It is indeed a strategic decision that falls under the purview of the company's leadership. Our role is limited to working on the Unix/Linux part of the project and ensuring that we adhere to the schedule, budget, and business functionalities defined by the leadership. If such a decision were to be considered, it would involve broader considerations that go beyond our technical responsibilities. We (aka projects team) are here to contribute to the project's success within the framework of the directives provided to us. > How about "Replace a locked-in solution with an fully open source > [hopefully] solution"? > > It definitely looks like there is no ready open source solution to the > component the OP wants to replace. It might be possible to adapt an > existing terminal emulator to include the necessary functionality, > solving the immediate problem, but the next part that they want to > replace might end up with the same problem. Certainly, that could certainly be a viable option, but from my perspective, it would look more like a future project that the leadership might consider launching in a few years. Currently, my focus is on completing the current project, which falls within my current responsibilities. > "Xterm 216" is unclear for me. PuTTY documentation in 4.4.3 Changing the action of the function keys and keypad explain it by "In Xterm 216 mode, the unshifted function keys behave the same as Xterm R6 mode. But pressing a function key together with Shift or Alt or Ctrl generates a different sequence containing an extra numeric parameter of the form (1 for Shift) + (2 for Alt) + (4 for Ctrl) + 1. For F1-F4, the basic sequences like ESC OP become ESC [1;bitmapP and similar; for F5 and above, ESC[index~ becomes ESC[index;bitmap~. " > The things missing there are "escape sequence to start sending stuff > via serial port to the printer" and "send everything coming from the > serial port to the app". > > I envision a small program in the middle of all spawning an SSH, > opening the serial port and running in an xterm (so your ssh is > just wrapped in that process). My limited knowledge of Expect (session login script automation) had led me to believe that Expect would not do the job, but I was wrong. Since Expect can be capable of detecting escape sequences and sending back data to the terminal based on these sequences. So, Expect can be used to monitor the output of a terminal, detect specific patterns, such as escape codes, and take actions accordingly, such as sending commands or interacting with the terminal. The small program described in the previous proposal could indeed be the intermediate filter. The intermediate filter acts as a kind of mediator between the terminal emulator (in this case, SSH running in an xterm) and the serial printer, redirecting data appropriately. In this scenario, the intermediate filter would be responsible for two main functions: Detecting escape sequences (as mentioned in the question) to know when to start redirecting data to the serial port of the printer. Taking data from the serial port of the printer and transmitting it to the terminal application (SSH in an xterm) seamlessly. Thus, this small program could be considered as a component of the intermediate filter, ensuring smooth data management between the terminal emulator and the serial printer. The component could be expect or a C/python/tcl/perl program. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, I will try to be more explicit in my request and avoid giving the impression that I'm avoiding the discussion of technical issues. As you mentioned, my previous response seemed to resemble the replies of corporate support teams, but I don't really fall into the category of "those who are afraid to disclose some knowledge they might have heard." I have shared all the information I possess as a system engineer regarding the solution we use, and I have even gone beyond my responsibilities (scope) by addressing the aspect of the workflow that falls under the domain of our application developers working on the functional side. However, I align more with the first category of individuals "who do not know the technical details" because I struggle to explore beyond the features offered by the proprietary emulator and other similar solutions that the project team has asked me to evaluate. The problem likely lies, as Abraham Maslow said, in the fact that "If your only tool is a hammer then every problem looks like a nail." I have been constrained in my thinking by wanting to replicate the same implementation as the one I am familiar with in proprietary offerings and I find it challenging to understand how another solution could provide the same outcome while being implemented differently. Do you expect something like that for Technical specifications for the required solution: Connection Security: Utilization of the SSH protocol to ensure a secure connection to the Linux server, replacing Telnet. Non-Printing Terminal in passthrough Mode: A terminal emulator is used to access a semi-graphical application with a text-based user interface. It should be capable of displaying multi-level grids and application selection menus seamlessly. Intermediate Filter: A filter in between that in response to escape-code-1 starts sending data to the serial port instead of the terminal application and switches back to the terminal application on receiving of escape-code-2. Development of a transparent and responsive intermediate filter to ensure a smooth user experience. This filter must handle incoming and outgoing commands without disruption. Detection of Escape Codes: The filter continuously monitors incoming data from the terminal emulator to detect the presence of specific escape codes, such as "escape-code-1" and "escape-code-2." Switching to the Serial Port: When the filter detects "escape-code-1" in the incoming data, it switches to a data redirection mode towards the output device, such as the serial port. From that point on, all incoming data is directed to the output device instead of being displayed in the terminal application, while it continues to monitor communication with the printer. Waiting for Returns: The filter remains attentive to returns of information coming from the serial printer. These returns may include information about the printing status, errors, or other relevant data. Handling Returns: When the filter receives returns from the serial printer, it directly transmits them to the terminal application without any modification or addition. Thus, information from the serial printer is relayed as is to the terminal application without altering the pass-through mode. Reception of "Escape-code-2": When the filter detects "escape-code-2" in the incoming data (usually sent from the terminal application), it ceases redirecting data to the output device. At this stage, it returns to the normal behavior of the terminal emulator, displaying data in the terminal application. Transparent Processing: Throughout this process, the filter ensures that the transition between data redirection to the output device and display in the terminal application occurs seamlessly, so the user doesn't notice any interruptions or disruptions in data display or printing. Synchronization with the Terminal Application: The intermediate filter must stay synchronized with the terminal application to correctly detect "escape-code-1" and "escape-code-2." It must react promptly when it detects these codes to switch between redirection and pass-through modes. Poor synchronization could lead to interruptions or unwanted disruptions for the user. Synchronization with the Serial Printer: The filter must also maintain synchronization with the serial printer to handle returns of information appropriately and transmit them to the terminal application at the right moment. Desynchronization with the serial printer could result in the loss of crucial information regarding the printing status or errors. Latency Minimization: To ensure precise synchronization, the filter must minimize latency in data and signal processing. Excessive latency could lead to synchronization issues and unwanted delays. Exception Handling: Synchronization must also be considered when handling exceptions, such as the
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
Hello, On my technical side, I don't have insight into the contractual aspect or the costs involved. I'm not involved in the bidding and proposal writing phases either. My role comes into play after project maanger send me companies solutions to evaluate them from a purely technical and security standpoint. If the solutions pass our initial technical evaluation (performed by the systems teams), they are then passed on to more specialized functional teams for further testing. I wasn't familiar with the English acronym TANSTAAFL (There ain't no such thing as a free lunch), but I completely agree with it. My internal technical specification is to have an equivalent to the commercial product I have on my Wyse PC for testing. The decision to promote Putty was mine as a Linux enthusiast and advocate for open-source software. It performed well in testing, except for the passthrough printing aspect. The only cost I'm aware of is that of a proprietary product I mentioned earlier, which is available on their website: "AnzioWin starts at $150.00* per PC with quantity discounts beginning at 10 copies. Anzio Lite starts at $40.00* per PC with quantity discounts beginning with a license for 10 PCs." So, if we consider the cost of the more expensive version and assume we have 1000 PCs, it would range from $150,000 to $75,000 without any discounts. I won't disclose the exact number of our PCs, but let's say it falls within the range of 500 to 1000. I assume that with the simple cost of software plus the undisclosed maintenance cost paid annually, we could allocate a budget for open-source development that would benefit our company and, subsequently, the community, especially if the open-source product becomes part of the official product branch with included maintenance. What I can say is that I have management's approval for my interactions with the community and exploring potential open-source alternatives. However, there are no guarantees at this point, as I haven't yet produced concrete results in terms of an open-source alternative or engaged with the community for further development, budget allocation, and associated assurances. My approach might be naive or clumsy because I'm not familiar with the customs and practices in this business field. For the time being, our project management team prefers that the system team engages with the community to find something and intervenes later on in the negotiation and commercial aspects. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > With free software, it might not be too costly to try out > suggestions like Putty. But I speak as someone with a university > background, not a company one. We might have had a bit more > freedom to mess around, and even mess up. And a small base of > sophisticated users rather than a large number of likely > unskilled users Your academic perspective is appreciated, and it is true that in the professional world, especially in the retail sector, compatibility with specific peripherals is crucial for the smooth operation of operations. > From a position of ignorance, I would have thought that serial > pass-through printing is necessarily bidirectional, if only for > flow-control, but UARTs can do that in hardware with RTS/CTS. > So it's unlikely that that's enough to support what the OP wants, > which is probably things like ink/paper supply or, when there's > a cash drawer installed, drawer open/closed; typical POS stuff. > And that's without taking into account the peripherals mentioned > above. Regarding the use of Putty, it appears that in some cases, it can partially meet our needs by allowing interactions such as printing tickets and opening the cash drawer. However, i also mentioned that some other operations do not work. It is important to note that Putty is primarily designed as a terminal emulator and may not be equipped to meet all the specific requirements of our retail application. As for the evolution of Putty, it is understandable that the developer has not responded to our contact attempts, and we respect their decision to maintain the software according to their own criteria. I also pointed out that we have proprietary emulator solutions that come with integrated hardware offerings, such as Wyse-type client terminals or Android tablets. These solutions meet our needs and provide the necessary services at a given cost. I just to emphasize that the diversity of options, whether open source or proprietary, is a wealth, as it allows each company to find the solution that best suits its needs. Ultimately, our goal is to find the best solution for our retail application, taking into account hardware compatibility, required features, and associated costs. While we are open to exploring open-source solutions if they can meet our needs, we also value the reliability and support that proprietary solutions can provide. We will continue to evaluate all available options, ensuring that we choose the approach that best aligns with our business requirements and technical considerations. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > Hm ok, it's all too much guesswork then. I understand that the lack of detailed information can make it challenging to provide precise solutions. I believe I have addressed these questions as accurately and honestly as possible in my previous response to Greg, while also incorporating the information we discussed earlier. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > See, now we're going in circles again. I already *asked* the OP to > explain the full picture, and they still only gave a partial answer. > > It has been hinted to us that there are more layers in the problem > than simply Server <--> PC --> Printer. We've been told that there > is another layer of devices connected to the Printer, although this > was never confirmed in the "big picture" answer. > > Apparently the (retail sales??) application on the server needs to > talk to all three layers of hardware: the PC (to display information > on the screen), the Printer (to generate ink on paper), and the other > devices beyond the Printer (reasons never given). Communication with > the devices beyond the Printer is apparently "bidirectional", meaning > the server application needs to be able to query one of these devices > and get information from it, which will cause application state to > be altered, information to appear on the screen, etc. Or maybe the > devices beyond the Printer are capable of initiating an async data > transfer to the server app? Who knows. It was never clearly stated. > > Apparently the OP has a proprietary Windows terminal emulator + telnet > client program (name never revealed?) that can already do everything, > and they want a Debian program that can be used in place of it. > > The problem for *us* is that we don't know what "everything" is (since > the OP is incapable of explaining it all), which makes it very hard > to find a program that can do "everything". I've tried to be as precise as I can in the technical description. I understand I'm seeking help, but it's challenging for me to provide specific product names and details without violating the security guidelines I've agreed to in this project, which is critical for our company. I have previously mentioned that this is a Point of Sale (POS) system, consisting of the workstation (Wyse-type) that includes the terminal emulator and the receipt printer. This setup is used in the retail sector, primarily for sales transactions. I cannot disclose the names of commercial products in use because we are simultaneously evaluating various proprietary products in a competitive pre-sales phase. My role is strictly technical, focused on providing unbiased, pragmatic, and fact-based assessments of solutions, whether they are proprietary or open source. I always provide detailed arguments and references whenever possible. I must avoid any potential legal issues that could arise from disclosing sensitive information to any of the product vendors involved in the project. Additionally, I don't use the application myself, and I'm not familiar with its functional aspects. My knowledge is limited to the technical aspects of how things work, more like a black-box perspective. I can, for example, mention that this guide explaining passthrough mode (https://www.anzio.com/resources/guide-anzios-passthrough-printing) is a proprietary product that could potentially meet our requirements. I can cite it because, as of now, the project team hasn't initiated any commercial contact with this vendor during the pre-sales phase. However, the technical principles are well described in this resource: https://www.anzio.com/resources/printing-anzio in the Passthrough Printing + Aux Printing section, along with this additional resource: https://www.anzio.com/resources/using-aux-devices-anzio. The current emulator comes bundled with the Wyse-type workstation equipment; we don't have access to this software independently. From a practical standpoint, when it comes to printing, we simply select the Passthrough Printing option and choose the COM port. That's all there is to it, and it works this way. It's almost the same as in PuTTY, except here, we can choose a hardware port instead of a virtual printer. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > Ok, and what's the problem? That the server wants to print to the > printer? That the application sends data to the "screen" (a terminal > emulator) instead of sending it to the printer? That it is necessary > to see the printer data displayed in a terminal emulator? The problem here revolves around the interaction between the terminal emulator, the application, and the printing process. The terminal emulator has a "printing passthrough" function, which means that depending on the user's interactions with the application, data can be displayed on the screen and, at times, passed through the terminal's passthrough mode to be printed on the physical printer. So, to address your questions specifically: 1. The server itself doesn't initiate printing; instead, it's the user on the workstation with the terminal emulator who wishes to print to their local printer. The application running on the server sends data to the user's screen (terminal emulator) and, when requested by the user, can be sent to the user's local physical printer connected to their workstation. 2. The application may send data to both the screen and the printer, depending on the specific user interactions and transaction requirements. The screen serves as a visual interface for the user, while the printer captures some of the data for hardcopy records. 3. It's necessary to have the option to selectively send certain data to the physical printer from the terminal emulator based on the user's choice, as it provides real-time feedback and visibility for the user during interactions with the application. However, not all data displayed on the screen needs to be sent to the printer, as it may include additional information or layout formatting relevant to the current screen content or user interactions. The display on the screen and the printing on the printer are designed to complement each other based on the specific transactional needs and the user's preferences. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, > It's running on a Windows PC. Walk into many a shop and you can see > the sort of setup, a PC and screen with a barcode scanner, keyboard, > credit card reader, receipt printer, etc, all hanging off it. The > server might be in an office, or perhaps at HQ or in the cloud. > All perfectly normal. The import of the thread is Windows → Linux. Yes, the challenge here is ideally to migrate the Windows-based workstation to Linux, provided that we have the necessary open-source emulator. Functionally, we already have proprietary alternatives that meet the requirements, but exploring open-source options is our preference, given our commitment to open-source solutions within our Linux environment. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >>> I don't understand why you involve a terminal emulator in the process. >>> Do you need to see the data that goes through the COM port displayed >>> in a terminal (like minicom)? >> >> People interact with the (remote) application by means of the terminal >> emulator. Things get sent to/from the printer based on escape sequences >> initiated by the application. >Desktop sharing works fine with gnome these days. Why not interact >with the application through that kinda locally? You suggest an interesting alternative by using the desktop sharing feature available with GNOME to interact with the application remotely. I was not aware of this particular use of the GNOME feature; I primarily knew it for remote control and screen sharing purposes. At this stage, I am not yet familiar enough with GNOME to provide a comprehensive opinion on this approach. However, I want to emphasize that within the scope of the mission I have been entrusted with, I do not have the authority to modify the server application's functionalities. I am subject to the constraints and decisions of the project team. Therefore, implementing this suggestion goes beyond the boundaries of my current responsibilities. >> In the original (proprietary) application, the dispatching functionality > > Dispatching functionality? > >> is integrated in the terminal emulator, so it is understandable that >> pheoebus phoebus wants to keep that structure in the replacement. In this project to migrate the application server from Unix to Linux, the primary objective was to maintain the stability and functionality of the server component, while the client side (the terminal) underwent an evaluation to explore open-source alternatives to the proprietary terminal emulator solution, all while preserving the existing functionality. > Well, I'd have to be quit a bit older to have experienced "real" > terminals like that. I do remember printers accepting some escape > sequences to control their functionality, though. > > If this application is running on such a terminal, maybe it's time to > find a more modern und thus more feasible replacement ... An ancient > terminal may cease to work eventually and be very difficult to repair > once it does ... This application does not run on a physical "real terminal" but on a terminal emulator, which is software running on a Windows-based workstation (Wyse). Currently, there are various hardware options available for this, including proprietary solutions with newer versions of Wyse and proprietary terminal emulators, as well as Android-based devices that can fulfill the task with proprietary emulators. However, as someone working with Linux and for whom open source and freedom have significance in my profession, I proposed to explore if there might be open-source solutions that can meet this requirement. If there are none available at this time, then so be it, but at least considering this option in our evaluation is an important step for us when it's feasible. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough"Printing
Hello, >> On the Linux server, are there multiple users logging into this server via >> ssh and each of them needs to print to a local printer in the way you >> mention? Yes, there are indeed multiple users logging into the Linux server via SSH and each of them needs to print to a local printer specific to their Point of Sale (POS) activity. This is essential because it involves a POS station and a printer specifically designated for this business activity. >> Would one normally attach a printer physically to the server and your >> software talk directly to this locally attached device on the server? I am >> curious how, if you have multiple users logging in, the software would know >> which ssh session to use to communicate with the local physical printer. Indeed, it is possible to physically connect a printer to the server and the software could communicate directly with this device through a print spooler system. However, in the context of our Point of Sale (POS) environment, this approach doesn't make sense. The printer needs to be dedicated to the POS station, ensuring that the staff using the PC is as close as possible to our customers and that the printing occurs directly in front of them quickly and seamlessly. In the case of SSH sessions, each user connects to the server with their individual session streams. The printing flow is, therefore, directed through this session in a straightforward and secure manner (which is the essence of printing in passthrough mode). >> When you say ‘serial port’ as in com1:, are you referring to an old RS422 or >> RS232 serial port? Or is the device connected to a USB and has an >> association with com1 on the windows side? When I mention a "serial port" like com1:, I am indeed referring to a traditional RS422 or RS232 serial port. If the device is connected via USB and is associated with a virtual com1 port on the Windows side, it doesn't require any software modifications to handle printing in passthrough mode. From the perspective of the proprietary terminal emulator, the data flow goes through a COM port, whether it's physical or virtual. >> I recommend that you do not try and modify PuTTY or KiTTY or any of the ssh >> terminals. This will be hard to support and you may cause a security >> nightmare. We absolutely refrain from attempting to modify software such as PuTTY, KiTTY, or SSH terminal emulators ourselves. This is because it can be challenging to implement and may pose security risks. Therefore, we are actively seeking to engage with the teams behind these projects to explore potential solutions that align with our needs or we are considering proprietary alternatives >> A possible solution is to run some small glue program on both sides of the >> connection which uses a port forward tunnel. For example, on the server, a >> small program which creates a pseudo device or named socket that looks like >> a local printer. This small program reads data on the pseudo dev and copies >> it to and from a local tcp port which is forwarded over ssh. Then, on the >> windows side, you write a second small program which listens on the local >> port and copies the data to and from com1:. Essentially you are building a >> tunnel from a device or socket on the server to the com port using an ssh >> tunnel between a local and remote tcp port. I cannot say if this solution would be viable when dealing with multiple users simultaneously. I don't have the flexibility to alter the behavior of the application, and this introduces constraints that I must consider when searching for an open-source solution to meet my requirements. Of course, if I opt for proprietary solutions, I have a clear path to solving my problem. >> If you have multiple people logging into the server, you will need to find a >> way to multiply the printer port on the server. This is why I asked about >> multiple users in my first question. I would need to understand that before >> making any recommendation around that. Off the top of my head, I would >> probably have my script create a named socket for each user in >> /run/user//foo/myprinter.sock and then in the software print to this >> socket which is unique for each user. >> Is there absolutely no way you can separate the part of your software that >> is running on the Linux server which talks bi-directionally to the printer >> and port this software to windows as a windows printer driver? Your >> situation seems a bit strange. I can’t help but think we’re missing >> something here. Developing on the Windows side for this printing functionality is not currently under consideration. Instead, the choice in this case would be to continue investing in a proprietary terminal solution, despite its cost, as it would provide more reassurance to the project team than the long-term expenses associated with maintaining this type of Windows development. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> People interact with the (remote) application by means of the terminal >> emulator. Things get sent to/from the printer based on escape sequences >> initiated by the application. >> >> In the original (proprietary) application, the dispatching functionality >> is integrated in the terminal emulator, so it is understandable that >> pheoebus phoebus wants to keep that structure in the replacement. I want to emphasize that your response reflects a clear understanding of our specific needs and the constraints we are facing in this project. >> I proposed splitting off the "mux" functionality from the terminal >> emulator functionality, but I fully understand that phoebus phoebus >> favours the more "conservative" approach. The use of a terminal emulator in passthrough mode is tied to our existing infrastructure and the way our application was originally designed. Within the scope of the ongoing project, which involves migrating our application from Unix to Linux, it is not within the migration's scope to alter this particular aspect, as it is both critical and sensitive. While I have some leeway to propose technical enhancements and changes, this specific area is off-limits due to its significant impact on a crucial functional aspect from both a business perspective and certain certification standards under which our POS system is certified. >> By the way -- back then (TM), when terminals were real things, it was >> not unheard of that they came with an attached printer and some bar >> code scannery -- all handily multiplexed over the RS-232 (or something >> more monstruous), orchestrated via intricate escapery. Yes, that's indeed how it used to work. In our case, the complex escapery you mentioned, for instance, involves the printing process using the ESC/POS printer control language. >> So the thing is just a natural evolution dating back to The Dinosaurs. While it may seem unusual and archaic by today's standards, this approach has proven to be an effective solution for addressing the needs of our business. It has been thoughtfully evaluated and retained because it ensures the efficient execution of our application while aligning with our business requirements. Just like certain evolutionary traits persist over time in the process of Darwinism, this approach endures, indicating that the choice isn't as misguided as it may appear. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I don't understand why you involve a terminal emulator in the process. >> Do you need to see the data that goes through the COM port displayed in a terminal (like minicom)? The existing solution is designed in that manner. We migrated our application from AIX to Linux, and this is the approach that has been historically used. On the client-side, we are exploring if there's an open-source alternative to the proprietary solution that fulfills the necessary functions. >> I do not understand what you are trying to do at all. Are you trying >> to print to a remote printer that has a serial port? For that, >> perhaps you could use a printserver with a serial port (if you can >> find one) or a printserver and an adapter from parallel to serial. In our POS system, the printer is located at the POS station so that our customers can have their prints quickly and in front of them. Printing from the server in this POS context doesn't make sense for us in this scenario. >> If you're trying to create a two-way communication between a remote >> server and a remote client, with the client sending and receiving the >> data through its COM port (for some weird reason), you could do that >> over ethernet, using your own protocol or an existing one (maybe even >> xmpp). We already utilize the TCP protocol for communication over Ethernet, as the transparent printing flow is encapsulated within the encrypted SSH stream. Depending on the ASCII control codes, the data either displays on the terminal screen or gets printed on the connected printer. So, we are already leveraging Ethernet and TCP for this purpose. >>Unfortunately, COM ports have become quite rare :( In the retail environment, COM ports are still quite common, especially in equipment such as POS printers. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I confess I have not read all messages. I think "expect" might be the program >> you need. Thank you for your suggestion and assistance. While 'Expect' is primarily designed to automate interactions with text-based programs, its use for intercepting and managing escape sequences to enable pass-through mode on a terminal screen is complex, particularly in the specific context and configuration of our POS system. Given that the terminal needs to interact very frequently and dynamically with the printer based on real-time feedback from the server, I believe that 'Expect' may not be the best solution for our situation. It is generally more suitable for scripted interactions and predictable scenarios. I appreciate your input, and if you have any alternative suggestions or insights that align more closely with our requirements, I would be grateful for your guidance. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> You don't mention it, but did you look at CKW (C-Kermit 10.0 for >> Microsoft Windows)? No, I didn't look into CKW 10, that's true. I skimmed through the description of Kermit 95 (from 2003) and that of C-Kermit 9 too quickly and didn't consider that CKW 10 is the full replacement for Kermit 95. >> In any event it seems it might be worth your time to contact the kermit >> developers as well as the putty developers. Yes, absolutely. Thank you for the advice. I will reach out to the Kermit project developers in addition to those of PuTTY. Thank you. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> One viable approach is the one proposed by Stefan et al (modify an >> existing terminal emulator). I'd tend to separate concerns and just >> write the application part as a separate process accepting a bidi >> connection to SSH, one to a terminal emulator, and one to the serial >> port (OK, some error and diagnostic logging too). The classical >> thing built around a select() loop, with some extended state >> automaton in it. I fully endorse the approach proposed by Stefan et al, as well as the implementation logic for the terminal emulator part. However, as a system administrator and not a developer, I will seek out existing projects or solutions that provide these features. Thank you once again for your valuable assistance. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Clearly we don't know of any terminal >> emulators that do what you want. (I assume you've already looked at >> kermit, and found it lacking... yes? OK then.) I want to express my sincere gratitude for pointing me to this project. I wasn't familiar with the Kermit terminal emulator before but after looking at their website, I believe that Kermit 95's feature set should address my needs. The features such as: * Copy/paste, print, searching, and bookmarks in the scrollback buffer * Host-directed and local printing * Versatile printer control, including bidirectional printers and built-in Text/PostScript conversion seem to align with my requirements. I also explored E-Kermit (Kermit for Embedding) since we were asked if there was an emulator that could perform these functions in an embedded environment. However, based on what it does not do, it doesn't seem to be the solution I was hoping for. Regarding the purely Linux/Unix C-Kermit, it appears to be less feature-rich compared to Kermit 95, so it may not be the best fit for my requirements. >> At this point, I don't think you're talking to the right mailing list. >> We're just Debian users. >> If you need new features to be added to an existing Free terminal >> emulator, or even to have a whole new one developed from the ground up, >> this is not the mailing list for that. My initial goal was to find an equivalent of a proprietary emulator for Linux, particularly on our preferred Debian platform. I completely agree that this mailing list is not the place to discuss adding features to an emulator or creating a new one from scratch. >> Find the project that comes >> closest to your needs, and talk to the developers of that project. I also agree that for the terminal emulator I want to enhance, I should locate the project and directly engage with their team. This is precisely what i'm trying to do with the PuTTY team. In any case, the Debian community through the constructive exchange has been tremendously helpful and beneficial in my search. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I take it that by "the proprietary software" you mean the proprietary >> terminal emulator running on the client PC. Yes, that's correct. "The proprietary software" refers to the proprietary terminal emulator running on the client PC. >> One thing you might be able to do quickly is establish an SSH tunnel >> between the PC and the server, then route the proprietary terminal >> emulator telnet traffic through the tunnel. That, at least, will get >> you a more secure connection between the PC and the server. We've actually tested that approach before, but it introduced several technical challenges, and even though we managed to resolve some of them, it added complexity to the maintenance process. Additionally, it's important to consider that our end-users are not IT professionals but individuals primarily focused on sales. We need to encapsulate the entire process in a way that's transparent to the user, involving opening a program that initiates an SSH session within a tunnel, followed by launching the proprietary emulator for a Telnet session within that tunnel. We're also revisiting our workstation authentication process to transmit information through it in order to identify different application sessions, as the application on the server appears to be originating from localhost. Furthermore, we're reevaluating the mechanism for checking the number of sessions originating from each workstation based on the assigned roles. We're addressing various technical aspects, but this solution was ultimately rejected by the project team as it was perceived as a workaround, not robust and fragile. It posed risks to the business in a critical part of our operations. >> If I understand things correctly, the server sends all sorts of >> information to the proprietary terminal emulator. Most of that gets >> displayed on the emulator. But, given one VT escape code, the emulator >> sends the subsequent data off to the printer, until it gets the other >> VT escape code. The printer may then return a response. Yes, that's the basic concept, but it's even more intricate. The application continuously monitors what it receives from the terminal with regular interval checks (in milliseconds) and makes decisions based on rules. These decisions include sending commands to the printer, analyzing the responses, taking user actions, and even restricting user input in certain menu or submenu areas of the screen. However, I have a high-level understanding of this process as I'm not part of the application development team to delve into the finer details. >> If that understanding is correct, I suggest you grab an existing open >> source terminal program that supports VT escape codes: >> >> 1) Modify how it handles those two escape codes. >> >> 2) Modify it to listen to the printer for responses, encode those >> appropriately, and ship them to the server. >> >> I haven't worked with VT escape sequences in decades. If I recall >> correctly, some escape sequences cause the terminal to send information >> back to the server. In that case, you may need to synchronize return >> information from the printer with other return information. Thank you for your suggestion. As I mentioned earlier, our development team primarily focuses on the server-side application and is not competent to modify the client-side emulator, which is crucial in our case. They have already examined the PuTTY source code and confirmed that this type of development is beyond their expertise. That's why we are exploring open-source solutions that offer a plug-and-play feature set or potentially an evolution of PuTTY. If we don't find a suitable open-source solution, we will consider commercial emulators that integrate this functionality. As a last resort, we might opt for a proprietary solution and pay for the licenses and maintenance required for the work done in that product. The suggestion you made to adapt an open-source terminal program to support VT escape codes is certainly relevant, but unfortunately, it goes beyond our current expertise and that of our team Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I'd just suggest checking with the PuTTY team before hand if they'd be >> interested in adding the functionality. Sure, a ready-to-apply patch >> increases the chances, but this seems like a very specific feature that >> very few people seem to need, so they might not want to add extra >> complexity to the software. You raise a valid point, and I appreciate your input. Before proceeding with any development or prototype, it would indeed be wise to reach out to the PuTTY team to gauge their interest in adding this specific functionality. Understanding their perspective on its relevance and complexity is crucial. I've already made initial contact but I'm still waiting for their response. I'll continue to pursue this avenue in the hope of receiving a response and initiating a dialogue. Thank you for highlighting this aspect of the process. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, I understand that the situation may seem complex and i apologize if my previous messages did not provide a clear overview of the problem. Allow me to summarize our current situation. In this response, I will incorporate the various comments made by Greg, Charles Tomas, and incorporate a significant portion of Greg's excellent summary. I have a client workstation with a proprietary terminal emulator running on Windows. This PC is connected to a POS printer via a COM serial port. The client workstation along with the printer and other connected devices, forms the client-side of our Point of Sale (POS) system. This client workstation is supported by various hardware devices, including barcode scanners and payment terminals. However, these barcode scanners and payment terminals are not within the scope of my current focus, which is to find open-source alternatives to proprietary solutions for our specific terminal emulator. The printer model is a Thermal Line Dot Printing type and it supports the ESC/POS command system, created by Epson, which provides efficient and functional commands for communication with the printer. For more information on ESC/POS, please refer to this site: https://download4.epson.biz/sec_pubs/pos/reference_en/escpos/index.html The client PC connects to the server via Telnet but now, as part of our project, it uses SSH for secure connections. **It initiates a connection to the server to establish an interactive session.** **At some point, the application will initiate a communication session to the "printer" and to the "other device" THROUGH the "printer", all tunneled THROUGH the telnet or ssh session using "bidirectional passthrough printing"**. Depending on the set of ASCII code sequences sent by the server, the terminal either displays characters on the screen or sends the command stream to the printer. In our case, it sends this stream to a serial port. All commands received by the printer begin with ESC (ASCII 27, HEX 1B) or GS (ASCII 29, HEX 1D), followed by another character specifying the command. Normal text elements are simply sent separated by line breaks to the printer. The passthrough printing concept is well explained in this guide by Anzio: https://www.anzio.com/resources/guide-anzios-passthrough-printing. Our server-side application, written in C, follows the same principle of code execution with the client workstation via the terminal emulator. Please note that our legacy proprietary terminal emulator is not the one provided by Anzio; however, in the context of considering a proprietary replacement solution, Anzio's solution is among those being evaluated. Our objective is to explore open-source solutions for this configuration as we aim to replace the proprietary software. I want to express my gratitude for your patience and valuable insights. Please let me know if this response now helps to clarify the situation. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Looking at >> https://www.chiark.greenend.org.uk/~sgtatham/putty/feedback.html#feedback-features >> suggests that you should try to design whatever features you require >> yourself in the first instance, and then submit it for consideration >> by the maintainers. And be prepared to implement it if required before >> submission to the project. I don't mean that you personally should do >> this, but rather that you should hire someone suitably qualified to do >> it. Specifically someone who is not part of the team, unless they >> volunteer. It sounds like their problem is lack of available effort. I genuinely appreciate these details and the clarification that I had overlooked. I will now discuss this information with our project team to determine the best way to incorporate it. This includes considering presenting the idea to our management and potentially engaging a qualified third party to design a prototype. The goal would be to further develop these features beyond the initial stage, so that the PuTTY project team can seamlessly integrate them (ideally in the form of a ready-to-use patch). >From my perspective, this approach offers distinct advantages over commercial >solutions in terms of licensing and maintenance costs. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Trish, >> PuTTY is Simon Tatham's - >> https://www.chiark.greenend.org.uk/~sgtatham/. You might have more >> success there. Thank you for the suggestion. I have also utilized the information from the commit (https://git.tartarus.org/?p=simon/putty.git;a=commit;h=b846178443cf1a5dc7c5ea2079fd34fd465af497) mentioned on the indicated website and it corresponds to the email address found on Simon Tatham's website. However, it's worth noting that the email associated with Mastodon for the domain in .io does not appear to exist. I will rely on the email from the commit for now and I appreciate your assistance. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> > Currently, PuTTY is an option but its current version has limitations >> > that make it insufficient for our operational use. >> >> >> Commission the PuTTY authors to add the missing features or pay someone >> else to do it if they aren't interested. >> >> https://www.chiark.greenend.org.uk/~sgtatham/putty/ I have already tried to contact the PuTTY development team using the email address pu...@projects.tartarus.org; however, I did not receive a response. Originally, my request in that email was to explore the possibility of commissioning the PuTTY authors or paying someone else to add these features in case the development team was not interested. My goal in funding this project would be to have the code integrated into the main PuTTY branch and become an integral part of official releases, thus avoiding obsolescence. However, outside of the PuTTY team, I am not certain of the best way to proceed to achieve this goal. Therefore, I wonder if the address pu...@projects.tartarus.org is the correct one to contact the project, and if anyone could suggest a more appropriate contact address or any other suggestions to advance this improvement proposal. Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> I've always used 'ser2net' for that for of thing, mostly with single- >> board computers attached via serial ports on a remote machine. But it >> doesn't matter what the device is, it's a dumb pipe to transfer bytes >> to/from a serial port on another computer. Thank you for indicating the use of 'ser2net'. I appreciate your suggestion and the information you provided. However, in our specific infrastructure, the terminal emulator plays a central role due to the way our users access the application and reauthenticate for printing purposes. This interaction is seamless for our users and the terminal emulator serves as a crucial component in managing the communication between the server and the various devices, including the printer and others. While 'ser2net' may be a valuable tool for certain purposes, it doesn't align with our specific requirements. Nevertheless, I'm grateful for the insight and knowledge you've shared. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Suggestion: Make another description of the challenge. >> >> Describe it as a travelling route. Spend effort on telling >> what the endpoints were and are. Our current starting point as being a third-party terminal emulator provided by a licensed company. This emulator runs on an outdated version of Windows and older Wyse versions and supports only the Telnet protocol, limiting our ability to establish secure connections. Now, our mandatory choice, if no other alternative emerges is to upgrade our infrastructure by transitioning to newer Wyse clients equipped with more recent versions of Windows and migrating to the commercial emulator from the same company (or another) which supports the SSH protocol and Passthrough Printing. We aim to migrate to an open-source terminal emulator that supports the Passthrough Printing, thereby offering improved security and this remains our preferred path. Currently, PuTTY is an option but its current version has limitations that make it insufficient for our operational use. We have conducted research in our quest to find such an open-source emulator with full Passthrough Printing, but thus far, we have been unable to identify one that fully meets our needs. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Is this also true of the Linux version of Putty? I've never used it but >> it's packaged in Debian. Also I wonder what it is you mean with >> "bidirectionally" here. Do you expect to read data from the printer and >> send it back? Yes, bidirectional communication is expected in both directions because behind this printer, several other devices are controlled through the printer, making the terminal a central point in the seamless interaction with the server for our users. What we aim to achieve is the ability to print directly to the COM port. While we are aware of commercial emulators that can accomplish this, we are exploring whether there are open-source alternatives that can provide the same functionality. Currently, this functionality is handled by a commercial emulator. >> Another thing I found with a quick search is screen. While screen is a >> terminal multiplexer, it has a user controllable setting printcmd for >> printing: >> >> "printcmd [cmd] >> >> If cmd is not an empty string, screen will not use the terminal >> capabilities "po/pf" if it detects an ansi print sequence ESC [ 5 i, but >> pipe the output into cmd. This should normally be a command like "lpr" >> or "'cat > /tmp/scrprint'". printcmd without a command displays the >> current setting. The ansi sequence ESC \ ends printing and closes the >> pipe. Warning: Be careful with this command! If other user have write >> access to your terminal, they will be able to fire off print commands." >> >> >From that description you should be able to set printcmd to for example >> cat > /dev/ttyUSB_whatever and the remote printing will go there. Screen does not have the capability to switch to transparent mode or specifically handle escape codes for printing natively, which it would receive from the application in order to pass to printcmd. Moreover, due to the continuous exchange based on the application's menus, managing this as an overlay to redirect the output to an external command could become quite complex. The printcmd feature in screen is primarily designed to redirect the output of the application to an external printing command. However, it is not intended to effectively handle bidirectional flows involving other devices. Thank you for the suggestion. Best Regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> Would it be correct to say that you don't care about the >> "terminal emulator" at all, and merely need a way for the Linux >> server to send data over the network to a serial port on a >> remote Debian machine which is attached to a printer? >> >> If so, I direct you to the sredird package. Thank you for suggesting this path. However, the terminal emulator plays a central role in our infrastructure because it is through this terminal emulator that users access the application and also have the ability to reauthenticate inside it for printing purposes. It's important to note that behind this printer, several other devices are controlled through the printer, making the terminal a central point in the seamless interaction with the server for our users. Therefore, the terminal emulator remains an integral component of our setup. Best regards, Thierry
Re: Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Hello, >> It should be pretty easy to take an existing terminal emulator and add >> the corresponding functionality. While it might seem straightforward to enhance an existing terminal emulator with the required functionality, in practice, it involves a significant amount of custom development work. Unfortunately, we currently lack the necessary skills and resources to execute this successfully. Addressing this challenge would indeed require substantial development efforts, which can be quite challenging for our administrative system. As a result, I'm actively exploring alternative solutions that are more readily available, particularly open-source options, which align better with our specific needs. Best Regards, Thierry
Seeking a Terminal Emulator on Debian for "Passthrough" Printing
Dear members of the Debian community, I am currently on the lookout for a terminal emulator on Debian that can handle controlled printing from a remote server often referred to as "passthrough" printing. Our specific requirement is the ability to select the printing device using a specific method, either the physical COM port or the virtual COM port (emulated by a USB device). To be more precise, we want the terminal emulator to transmit data exactly as it is received from a remote server (which is a Linux server) when it attempts to print data through a set of escape sequences to send text in transparent mode. This transmission should be directed to the COM device without any modifications. We have noticed that PuTTY allows "passthrough" printing but unfortunately, it only works unidirectionally and requires the use of a serial software printer which also supports only unidirectional flow. While PuTTY can manage connections to devices via the serial port bidirectionally, it does not provide a solution to manage "passthrough" printing directly to the COM port. This configuration is described in the PuTTY documentation (https://documentation.help/PuTTY/config-printing.html). Our application runs on Linux and needs to communicate with a specialized serial printer by sending data directly to it through a terminal emulator on a client machine (with the printer connected to the client machine's serial port). The purpose of my request is to explore the possibility of moving away from a third-party terminal emulator that runs on Windows and is compatible with somewhat older hardware and operating systems. I have conducted research within the list of available emulators on Debian but have not yet found a solution that meets our requirements. Therefore, I am reaching out to seek your assistance and suggestions. I have tried Tera Term (https://osdn.net/projects/ttssh2/releases/) but it does not offer the desired functionality. If you have any ideas or recommendations for a Debian terminal emulator capable of bidirectional "passthrough" printing, I would greatly appreciate hearing from you. Thank you in advance for your assistance and valuable suggestions. Best regards, Thierry
Re: set the number of inodes during FS creation via pressed
Hello, Thanks for the advice. Le lundi 15 novembre 2021, 01:40:46 UTC+1, David a écrit : >> Hello, >> >>Sorry, I do not have any additional knowledge about this. >>But, I think you will have another chance to receive help >>if you ask your entire question again on the mailing list for >>discussion about the debian-install system: >> https://lists.debian.org/debian-boot/ I sent an email to the list with the subject: "set the number of inodes during FS creation via pressed (specify_usage)" Regards, Thierry
Re: why Debian?
Hello, The reasons I chose them is that Debian is considered a stable and reliable OS (the policy of the OS is not to include as many and as much quickly as possible new features), and that it has a large and dependable community. Debian stable release(currently 11 bullseye) is the most stable distro as It's tested by not only it's maintainers but Also by its downstream maintainers for Offshoot distros(which include both commercial and community) and their users as well It has some strict policies for being stable including seperation of free and non-free software, source only uploads, Reproducible builds of packages. Debian maintainers are highly Experienced. Some of the package maintainers are also upstream authors Most software is tested on Debian/Debian based distros (manual or CI). Which makes it even more robust in practice. Eg. Android. Indeed Debian Linux kernel is the most used kernel of all distros (including kernel.org source builds). Debian community is very large in that you get 24hrs support as its community is wide spread across the world and so are security patches Sure you know it but just mention this link: https://www.debian.org/intro/why_debian https://wiki.debian.org/WhyDebian Regards, Thierry
Re: set the number of inodes during FS creation via pressed
Thanks for the update.
>>From there I found this file for bullseye:>>
>>https://preseed.debian.net/debian-preseed/bullseye/amd64-main-full.txt>>which
>> contains this stanza which appears to match your description:
>>### Description: Typical usage of this partition:
>># Please specify how the file system is going to be used, so that>>#
>>optimal file system parameters can be chosen for that use.>># .>># standard
>>= standard parameters,>># news = one inode per 4KB block,>># largefile =
>>one inode per megabyte,>># largefile4 = one inode per 4 megabytes.>># d-i
>>partman-basicfilesystems/specify_usage select >># Possible choices:
>>${CHOICES}Which is not what the OP requested, but maybe it helps. It is
>>the only>>occurrence of "inode" in that file. I did not check the other two
>>files>>that contain the "contrib" and "non-free" data.
I tryed to adapt like this with this option: **specify_usage{ }**
--
1024 1024 2048 ext4 \ lv_name{ var+log } \
method{ lvm } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var/log } \
options/nodev{ nodev } \
options/nosuid{ nosuid } \
options/noexec{ noexec } \
$lvmok{ } \
. \
1024 1024 2048 ext4 \
lv_name{ var+loga } \
method{ lvm } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var/loga } \
options/nodev{ nodev } \
options/nosuid{ nosuid } \
options/noexec{ noexec } \
specify_usage{ news } \
$lvmok{ } \
. \
1024 1024 2048 ext4 \
lv_name{ var+logb } \
method{ lvm } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var/logb } \
options/nodev{ nodev } \
options/nosuid{ nosuid } \
options/noexec{ noexec } \
specify_usage{ large } \
$lvmok{ } \
. \
1024 1024 2048 ext4 \
lv_name{ var+logc } \
method{ lvm } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var/logc } \
options/nodev{ nodev } \
options/nosuid{ nosuid } \
options/noexec{ noexec } \
specify_usage{ large4 } \
$lvmok{ } \
. \
1024 1024 2048 ext4 \
lv_name{ var+logd } \
method{ lvm } format{ } \
use_filesystem{ } filesystem{ ext4 } \
mountpoint{ /var/logd } \
options/nodev{ nodev } \
options/nosuid{ nosuid } \
options/noexec{ noexec } \
specify_usage{ standard } \
$lvmok{ } \
. \
--
But this change nothing after verfication the bytes per inode is 16k in all
case. ( = x / )--
root@debian:~# dumpe2fs /dev/mapper/rootvg-var+log | grep -E "(Block
count|Block size|Inode count)"
dumpe2fs 1.46.2 (28-Feb-2021)
Inode count: 62464
Block count: 249856
Block size: 4096
root@debian:~# dumpe2fs /dev/mapper/rootvg-var+loga | grep -E "(Block
count|Block size|Inode count)"
dumpe2fs 1.46.2 (28-Feb-2021)
Inode count: 62464
Block count: 249856
Block size: 4096
root@debian:~# dumpe2fs /dev/mapper/rootvg-var+logb | grep -E "(Block
count|Block size|Inode count)"
dumpe2fs 1.46.2 (28-Feb-2021)
Inode count: 62464
Block count: 249856
Block size: 4096
root@debian:~# dumpe2fs /dev/mapper/rootvg-var+logc | grep -E "(Block
count|Block size|Inode count)"
dumpe2fs 1.46.2 (28-Feb-2021)
Inode count: 62464
Block count: 249856
Block size: 4096
root@debian:~# dumpe2fs /dev/mapper/rootvg-var+logd | grep -E "(Block
count|Block size|Inode count)"
dumpe2fs 1.46.2 (28-Feb-2021)
Inode count: 62464
Block count: 249856
Block size: 4096
root@debian:~#--
Tryed also with
---d-i
partman-basicfilesystems/specify_usage select news
--
And ugly workaround will be to update inode_ration into /etc/mke2fs.conf with
sed via
-
d-i partman/early_command string \ sed -i 's/inode_ratio = 16384/inode_ratio
= 4096/g' /etc/mke2fs.conf
but it apply to all FS.
/etc/m
set the number of inodes during FS creation via pressed
Hello all,
Do you know if it possible to set the number of inodes to create in the
filesystem during the installalation with the pressed file?
If i start from this example for the filesystem /var/log, how to set numbers of
inodes inside it ?
500 550 1024 ext4 \ lv_name{ varlog } \
method{ lvm } format{ } \
use_filesystem{ } filesystem{ ext4 } \
label{ varlog } \
mountpoint{ /var/log } \
options/nodev{ nodev } \
options/nosuid{ nosuid } \
options/noexec{ noexec } \
options/relatime{ relatime } \
$lvmok{ } \
. \
Hope to do it as mkfs do it: mkfs -t ext4 -N iNumberOfINodes /dev/XdY ?
Thanks for your advise?
Regards,
Thierry
